Directus integrated MCP: how to reduce token usage?

Help
1

i am using the Directus built-in MCP with Claude Code (and very happy that it exists).

But the token usage is a bit off.
Here’s the token usage shown with /context command

     └ mcp__directus-claude__system-prompt (directus-claude): 594 tokens
     └ mcp__directus-claude__items (directus-claude): 4.2k tokens
     └ mcp__directus-claude__files (directus-claude): 4.1k tokens
     └ mcp__directus-claude__folders (directus-claude): 1.5k tokens
     └ mcp__directus-claude__assets (directus-claude): 692 tokens
     └ mcp__directus-claude__trigger-flow (directus-claude): 2.9k tokens
     └ mcp__directus-claude__schema (directus-claude): 2.1k tokens

This is huge! Compare this to Chromde DevTools for example:

  └ mcp__chrome-devtools__list_console_messages (chrome-devtools): 584 tokens
 └ mcp__chrome-devtools__emulate_cpu (chrome-devtools): 651 tokens
 └ mcp__chrome-devtools__emulate_network (chrome-devtools): 694 tokens
 └ mcp__chrome-devtools__click (chrome-devtools): 636 tokens
 └ mcp__chrome-devtools__drag (chrome-devtools): 638 tokens
 └ mcp__chrome-devtools__fill (chrome-devtools): 644 tokens
 └ mcp__chrome-devtools__fill_form (chrome-devtools): 676 tokens
 └ mcp__chrome-devtools__hover (chrome-devtools): 609 tokens
 └ mcp__chrome-devtools__upload_file (chrome-devtools): 651 tokens
 └ mcp__chrome-devtools__get_network_request (chrome-devtools): 618 tokens
 └ mcp__chrome-devtools__list_network_requests (chrome-devtools): 783 tokens
 └ mcp__chrome-devtools__close_page (chrome-devtools): 624 tokens
 └ mcp__chrome-devtools__handle_dialog (chrome-devtools): 645 tokens
 └ mcp__chrome-devtools__list_pages (chrome-devtools): 582 tokens
 └ mcp__chrome-devtools__navigate_page (chrome-devtools): 642 tokens
 └ mcp__chrome-devtools__navigate_page_history (chrome-devtools): 656 tokens
 └ mcp__chrome-devtools__new_page (chrome-devtools): 637 tokens
 └ mcp__chrome-devtools__resize_page (chrome-devtools): 629 tokens
 └ mcp__chrome-devtools__select_page (chrome-devtools): 619 tokens
 └ mcp__chrome-devtools__performance_analyze_insight (chrome-devtools): 648 tokens
 └ mcp__chrome-devtools__performance_start_trace (chrome-devtools): 689 tokens
 └ mcp__chrome-devtools__performance_stop_trace (chrome-devtools): 586 tokens
 └ mcp__chrome-devtools__take_screenshot (chrome-devtools): 803 tokens
 └ mcp__chrome-devtools__evaluate_script (chrome-devtools): 775 tokens
 └ mcp__chrome-devtools__take_snapshot (chrome-devtools): 614 tokens
 └ mcp__chrome-devtools__wait_for (chrome-devtools): 643 tokens
  • Is there a way to reduce the available tools via configuration?
  • Is the Directus Team working on a solution for this?

Thank you!

1 Like
2

It’s a tricky balance between token usage and reliability of the tool. During development there was a time where the tokens where 10× what they are now and it worked even more reliably :woozy_face:

@bryantgillespie any additional context?? You’ve spent the most time in the deep end here :slight_smile:

3

Thanks for the bump Rijk. Indeed I am in the deep end of this. :melting_face:

Great topic and great question @Jehu ! And one that I personally wrestled with a lot with during the latest MCP Release.

Spoke a little bit about it here, but we’re definitely aware of the heavier token usage. It was a conscious decision we made when shipping that latest release with the MCP.

In the tradeoff between higher token costs vs (reasonably) reliable results – we chose better results.

If you look at things like creating / managing schema in Directus, you have not only the underlying SQL schema we have to account for but also the metadata for the UI (interfaces, displays, etc)

It’s a lot of complex data with a lot of possible combinations that unfortunately has to be highly accurate or bad things will happen :anxious_face_with_sweat:.

The only way to inform the LLM of that structure is to give it specific detailed examples which have a high token cost.

All that said - we’re actively working on ways to reduce the token usage while ensuring we still get the level of reliability we expect.

We’ve got a few promising concepts that I think will solve the problem, but we’re not willing to ship until we can prove the results are 100% as good or better.

For a quick fix today, would definitely recommend disabling the tools you’re not using or don’t plan to use in that session. So if you’re not working with files and folders or flows and operations – just disable those tools for the session so they don’t eat into your context window.

Long term though - we got you :smiley::raised_fist:.

4

thanks for the reply. However, I cannot find any information in the documentation about how to deactivate tools. It was documented for the former MCP but not for the new MCP integrated into Directus.

Also i can’t disable specific tools with Claude Code. Even when denying the access, the tools are loaded and eats tokens (see [FEATURE] MCP Tool Filtering: Allow Selective Enable/Disable of Individual Tools from Servers · Issue #7328 · anthropics/claude-code · GitHub).

5

Oh ok. Got it. I hadn’t realized that you couldn’t disable individual tools through Claude Code. From that doc, it looks like you can set permissions to not allow it but it still gets loaded into the context window.

Please accept my apologies for the quick fix that doesn’t fix the problem :sweat_smile: :folded_hands:

Most other clients let you disable individual tools so this wasn’t on our radar in that last release.

I think the long-term fix is still one of the concepts that we’ve got around progressively loading tool context rather than implementing the ability to turn off specific tools on the server side.