This page compares common C# agent workflows. The estimates are practical planning numbers for agent interaction cost and prompt context.
Basic CLI is excellent for literal search and build parity. LSP is excellent for editor-local navigation. GliderMCP is built for agents that need structured semantic evidence they can reuse across multiple steps.
| Workflow | Basic CLI | LSP | GliderMCP | Why it matters |
|---|---|---|---|---|
Project and solution diagnostics get_diagnostics diagnostic_hotspots | Calls: 1-3 build or test commands plus log filtering. Tokens: High: build logs often include duplicate messages and unrelated output. Correctness / safety: Build output is authoritative, but the agent must group file, project, and solution impact itself. | Calls: Several diagnostic reads, often shaped by open files or editor state. Tokens: Medium: diagnostics are concise, but project-wide grouping depends on the client. Correctness / safety: Accurate for the editor workspace, weaker as a repeatable agent workflow. | Calls: 1 MCP call for filtered diagnostics or hotspot grouping. Tokens: Low to medium: structured diagnostics for files, projects, and whole solutions with paging. Correctness / safety: Project-aware diagnostics and grouped hotspots help the agent fix the right failure first. | Agents need to know whether a change broke one file, one project, or the whole solution before editing again. |
Find real references, implementations, and overrides find_references find_implementations find_overrides | Calls: 2-6 searches plus file reads. Tokens: High: matching names pulls in comments, strings, overloads, and unrelated code. Correctness / safety: Text matches are useful clues, not proof that code is related. | Calls: 1-3 symbol queries once the exact symbol is selected. Tokens: Medium: returned locations are focused, but broader cleanup needs stitching. Correctness / safety: Good for a known symbol in the current workspace. | Calls: 1-2 MCP calls: resolve the symbol, then ask for the relationship. Tokens: Low: paged relationship results with stable symbol identity. Correctness / safety: Direct relationship evidence avoids changing the wrong overload, interface, or similarly named member. | Safe edits depend on real code relationships, not every place the same text appears. |
Discover and resolve the right symbol find_code search_symbols resolve_symbol get_symbol_at_position | Calls: 2-6 searches and file reads. Tokens: Medium to high: the agent must inspect candidates to disambiguate. Correctness / safety: Names in comments, strings, and duplicate types are easy to confuse. | Calls: Several search, definition, or cursor-position hops. Tokens: Medium: good snippets, but symbol identity can be lost across later steps. Correctness / safety: Strong when the cursor already points at the right symbol. | Calls: 1 MCP call for search, resolve, cursor lookup, or find-code routing. Tokens: Low: candidate lists include reusable symbol keys. Correctness / safety: Stable symbol keys let the agent carry identity into references, callers, and refactors. | Most bad code edits start with the model acting on the wrong declaration. |
Trace callers, outgoing calls, and change impact find_callers get_outgoing_calls analyze_change_impact get_cascade_impact | Calls: Many method-name searches plus manual inspection. Tokens: High: call sites, overloads, and surrounding files pile up quickly. Correctness / safety: Manual tracing misses indirect paths and similarly named methods. | Calls: Several call-hierarchy hops. Tokens: Medium: local call hierarchy is focused, but transitive impact needs orchestration. Correctness / safety: Good around a selected method, less direct for agent-scale impact summaries. | Calls: 1 MCP call for direct callers/outgoing calls; 1 call for bounded cascade impact. Tokens: Low to medium: structured call edges and impact summaries. Correctness / safety: The agent can inspect blast radius before choosing where to patch. | Behavioral regressions follow execution paths, not file names. |
Inspect bounded type, method, and source context get_type_info get_method_signature get_type_source get_method_source | Calls: 1-4 file reads after locating the file. Tokens: Medium to high: whole files are often larger than the question. Correctness / safety: The agent must decide which ranges matter. | Calls: Several definition, hover, and outline hops. Tokens: Medium: snippets are useful but editor-shaped. Correctness / safety: Good for navigation, less compact for repeatable agent reasoning. | Calls: 1 MCP call for the requested type, method, signature, or bounded source. Tokens: Low: source and metadata are scoped to the requested member. Correctness / safety: Bounded reads reduce prompt flooding while keeping the relevant code visible. | The model should spend tokens understanding the change, not rereading unrelated source. |
Perform safe semantic refactors rename_symbol move_type move_member | Calls: Search-and-replace plus repeated diff review. Tokens: High: every match and changed file needs inspection. Correctness / safety: Risky around comments, strings, overloads, and unrelated symbols. | Calls: 1 editor refactor flow after selecting the symbol. Tokens: Medium: previews may be editor-local and hard to reuse in an agent transcript. Correctness / safety: Strong in an editor host when the selected symbol is correct. | Calls: 1 preview or apply MCP call after resolving the target. Tokens: Low to medium: affected locations and changed-file evidence are structured. Correctness / safety: Previewable semantic changes preserve symbol identity across files and projects. | Refactors should update the code relationship, not every matching string. |
Find unused code and project references find_unused_symbols find_unused_parameters find_unused_project_references | Calls: Several searches, builds, and manual checks. Tokens: High: absence of text matches is hard to prove from raw files. Correctness / safety: Deletion decisions are risky without build-aware evidence. | Calls: Several diagnostics or reference checks where exposed. Tokens: Medium: helpful local evidence, but project-reference cleanup is uneven. Correctness / safety: Good for obvious unused members, less direct for broad cleanup. | Calls: 1 MCP call for each cleanup question. Tokens: Low to medium: candidates are grouped with source evidence. Correctness / safety: Unused symbols, parameters, and project references are reported as actionable cleanup candidates. | Cleanup needs evidence strong enough to avoid deleting public APIs, reflection targets, or project dependencies accidentally. |
Inspect external definitions and package usage view_external_definition find_external_dependency_usages find_package_usages | Calls: Package cache inspection, docs lookup, and repo searches. Tokens: Medium to high: docs and package metadata can be detached from local usage. Correctness / safety: Docs may not match the referenced assembly or how the project uses it. | Calls: Metadata/source navigation when configured. Tokens: Medium: definitions are focused, usage summaries need extra work. Correctness / safety: Good for inspecting an API surface in capable editors. | Calls: 1 MCP call for external definition or package usage evidence. Tokens: Low to medium: definitions and concrete local usages stay together. Correctness / safety: The agent can connect external API behavior to the project code that depends on it. | Framework behavior often explains local bugs, but the useful evidence is where that API is actually used. |
Understand project graph, type dependencies, and complexity get_project_graph get_type_dependencies find_unused_project_references analyze_complexity | Calls: Multiple project-file reads, builds, and hand-built notes. Tokens: High: project graphs and dependency lists are too large to infer from scattered text. Correctness / safety: Hidden project dependencies are easy to miss. | Calls: Several symbol or project-context hops. Tokens: Medium: useful local context, but graph summaries are not always exposed. Correctness / safety: Good for navigation, less direct for architecture-level cleanup. | Calls: 1 MCP call for graph, dependency, unused-reference, or complexity views. Tokens: Low to medium: summaries are structured, paged, and project-aware. Correctness / safety: The agent can reason from architecture facts before moving code or deleting dependencies. | Architecture work needs a map before the model starts editing individual files. |