enh: Create "depth" flags for tool sophistication to avoid overwhelming context

[taylorwilsdon]

I love the idea of this project being the most capable/sophisticated control of this type of stuff down to the tiniest nuance, but I also do wonder if we eventually need to make certain "classes" of tools (ie degree of sophistication) optional because small models may start to struggle with this much tool usage context.

Proposal: Optional "Classes" of Tools to Improve Compatibility with Smaller Models

The google_workspace_mcp project is shaping up to be the most capable and sophisticated control layer of its kind — down to the tiniest nuance. This level of comprehensiveness is a strength, but it may also introduce challenges when working with smaller or more resource-constrained models.

Right now, the MCP exposes ~75 tools across a wide range of functions. While this gives maximum flexibility to advanced LLMs, the large tool surface area could overwhelm smaller models or lead to degraded performance when they attempt to process all tool usage context at once.

This proposal suggests introducing optional “classes” of tools, grouped by sophistication or intended usage, so that integrators can tailor the toolset to their specific model’s capabilities.

Current state: All tools are exposed by default. Smaller models may:

• Struggle with prompt/tool selection due to overwhelming context size.

• Fail to make effective use of highly specialized tools.

• Exhibit slower or less accurate performance because of excessive tool choice complexity.

Desired outcome is a way to maintain the power of the full suite for capable models, while allowing developers to selectively enable subsets for lighter or more focused deployments.

Proposed Approach

1. Tool Classification

   • Organize tools into logical "classes" or tiers based on:

     • Sophistication (basic, intermediate, advanced)
     • Domain focus (e.g., Calendar, Drive, Gmail, Search)
     • Complexity of input/output

   • Example:

     • Core Tools: CRUD operations, basic search.
     • Intermediate Tools: Multi-step queries, batch operations.
     • Advanced Tools: Complex cross-service orchestration, fine-grained query customization.

2. Configuration Mechanism

   • Add configuration options in config.json or environment variables to enable/disable specific classes.

   • Support multiple selection strategies:

     • By tier (e.g., "tool_tier": "core")
     • By domain (e.g., "enable_calendar": true)
     • By explicit allowlist/denylist (e.g., enabled_tools=["calendar.create_event", "drive.upload_file"])

3. Developer Guidance

   • Update documentation to:

     • Describe tool classes and their intended use.
     • Provide recommendations for different model sizes and capabilities.
     • Offer quick-start presets for “minimal,” “balanced,” and “full” configurations.

---

Benefits

• Better performance for smaller or less capable models by reducing cognitive/context load.
• Flexibility for developers to fine-tune exposed functionality without modifying source code.
• Improved maintainability by having a clear organizational structure for tool definitions.

---

Potential Drawbacks

• Additional configuration complexity.
• Slight overhead in maintaining tool classification metadata.
• Some risk of fragmentation if different deployments use very different subsets (mitigated by clear documentation).

---

Open Questions

• Should classification be based purely on capability tiers or on service domains?
• How granular should configuration be — per tool, per class, or both?
• Do we want to support runtime switching of toolsets based on dynamic model evaluation?

Originally posted by @taylorwilsdon in [#155 (comment)](#155 (comment))

[taylorwilsdon]

#176