This page compares common TypeScript and JavaScript agent workflows. The estimates are practical planning numbers for agent interaction cost and prompt context.
Basic CLI is excellent for literal search and package scripts. LSP is excellent for editor-local navigation. TGlider is built for agents that need reusable semantic evidence across packages, projects, exports, diagnostics, and refactors.
| Workflow | Basic CLI | LSP | TGlider | Why it matters |
|---|---|---|---|---|
Workspace and package orientation load get_workspace_root list_workspace_projects get_projects | Calls: Several package/config reads plus manual notes. Tokens: Medium to high: package files and configs include unrelated scripts and metadata. Correctness / safety: The agent must infer project ownership, workspace packages, and config shape itself. | Calls: Several editor or project-context queries. Tokens: Medium: useful local context, often limited to the opened project. Correctness / safety: Good in the current editor, weaker for monorepo-wide package topology. | Calls: 1-3 MCP calls for workspace root, projects, and package entries. Tokens: Low: compact workspace and package summaries. Correctness / safety: The agent can establish ownership before touching files across package boundaries. | Most monorepo mistakes start with editing the right name in the wrong package. |
Diagnostics and hotspot triage get_diagnostics diagnostic_hotspots | Calls: 1-3 typecheck/build commands plus log filtering. Tokens: High: TypeScript output can repeat related errors across projects. Correctness / safety: Compiler output is authoritative, but grouping and prioritization are left to the model. | Calls: Several diagnostic reads shaped by open files or editor state. Tokens: Medium: diagnostics are concise but not always grouped for agent planning. Correctness / safety: Strong locally, less repeatable across whole workspaces. | Calls: 1 MCP call for filtered diagnostics or grouped hotspots. Tokens: Low to medium: paged diagnostics grouped by file, project, category, or code. Correctness / safety: The agent can fix the highest-signal failure first and verify the same scope after edits. | Agents need to know whether a change broke one file, one project, or the workspace. |
Find the right symbol find_code search_symbols get_symbol_at_position get_symbol_info | Calls: 2-6 searches and file reads. Tokens: Medium to high: duplicate names, tests, comments, and generated declarations add noise. Correctness / safety: Text matches can confuse type/value symbols, aliases, and similarly named exports. | Calls: Several definition, outline, or hover hops once the cursor is close. Tokens: Medium: snippets are focused but symbol identity can be lost between steps. Correctness / safety: Strong when the editor selection is already correct. | Calls: 1 MCP call for semantic routing, search, or cursor lookup. Tokens: Low: candidates include reusable symbol keys and spans. Correctness / safety: Stable symbol keys carry identity into references, callers, exports, and refactors. | Bad JS/TS edits often begin by acting on a matching name instead of the intended symbol. |
Trace references, implementations, and API exports semantic_query find_references find_implementations list_exports list_project_apis | Calls: Several searches across source, tests, barrels, and package entry points. Tokens: High: import text, comments, and aliases pile up quickly. Correctness / safety: The agent must manually separate public API, local references, and unrelated text. | Calls: 1-4 symbol/reference queries from a selected symbol. Tokens: Medium: good local locations, less direct for package API summaries. Correctness / safety: Strong around a selected symbol, weaker for export-surface planning. | Calls: 1-3 MCP calls for references, implementations, and export/API surfaces. Tokens: Low to medium: structured results with symbol keys and file spans. Correctness / safety: The agent can connect local usage to public API shape before changing exports. | Export and reference mistakes break consumers even when local names still compile. |
Understand dependency topology get_project_dependencies get_file_dependents find_dependency_path detect_cycles | Calls: Many import searches and package/config reads. Tokens: High: dependency graphs are hard to infer from scattered source. Correctness / safety: Manual graph reconstruction misses re-exports, aliases, and project boundaries. | Calls: Several file and project navigation hops. Tokens: Medium: focused but often not summarized as a graph. Correctness / safety: Useful locally, less direct for architecture-level edits. | Calls: 1 MCP call for dependency edges, dependents, paths, or cycles. Tokens: Low: compact graph evidence with project/file ownership. Correctness / safety: The model can reason about import direction before moving code or changing package boundaries. | Architecture changes need dependency facts, not a pile of import statements. |
Trace callers and impact find_callers get_outgoing_calls analyze_change_impact get_cascade_impact | Calls: Many function-name searches and manual call-site reads. Tokens: High: overload-like shapes, callbacks, and similarly named functions add noise. Correctness / safety: Manual tracing can miss indirect callers and dependent package impact. | Calls: Several call hierarchy hops. Tokens: Medium: focused around a selected function, but transitive summaries need orchestration. Correctness / safety: Good for local call hierarchy when supported by the editor. | Calls: 1 MCP call for direct calls or direct impact; 1 call for bounded cascade impact. Tokens: Low to medium: structured caller and blast-radius summaries. Correctness / safety: The agent can inspect behavior paths before deciding where to patch. | Behavioral regressions follow call paths, package boundaries, and exported APIs. |
Live document analysis open_document update_document apply_document_edits translate_document_position close_document | Calls: Manual temp files or saved edits plus repeated typecheck commands. Tokens: Medium to high: disk state and edited state are easy to mix up. Correctness / safety: Agents can accidentally analyze stale files after in-memory edits. | Calls: Editor-native state is strong when the client exposes it. Tokens: Low to medium: depends on what the agent can access from the editor host. Correctness / safety: Strong in editor flows, less portable across MCP clients. | Calls: 1-2 MCP calls to open/update live text, then normal semantic tools use that state. Tokens: Low: no need to paste whole unsaved files repeatedly. Correctness / safety: Semantic reads, diagnostics, and positions stay aligned with in-memory edits. | Agents often plan against unsaved changes; stale disk analysis creates wrong conclusions. |
Safe rename and cleanup compute_rename_edits rename_symbol find_unused_symbols find_unused_parameters | Calls: Search-and-replace plus repeated diff and typecheck review. Tokens: High: every match and changed file needs inspection. Correctness / safety: Risky around strings, comments, exports, aliases, and unrelated symbols. | Calls: 1 editor rename flow after selecting the symbol. Tokens: Medium: previews may be editor-local and hard to reuse in an agent transcript. Correctness / safety: Strong when the selected symbol and project scope are correct. | Calls: 1 preview call before rename apply; 1 cleanup call per cleanup question. Tokens: Low to medium: affected files, warnings, and candidates are structured. Correctness / safety: Preview-first rename and conservative cleanup reduce accidental broad edits. | Refactors should update semantic relationships, not every matching string. |