Is MCP server with Claude 4 (Pro) using too many tokens?

[qualita]

I’m testing it with my Claude Pro account/email and the quota gets maxed out really fast — is this expected or am I missing something?

[eirikb]

Hi there. This has been discussed on Discord as well. And I believe it is indeed using too many tokens.

There are some things we can do about this, such as limit the descriptions and complexity. The agent you use will send this to the LLM, and it will eat a lot of tokens.
If the LLM decides to produce commands that doesn't extensively limit the JSON output from Graph API the actual internaction with MS will also eat a lot of tokens.

My dream plan is to (as I've done before) set up a proxy between say claude code and the claude API to see what goes over the line - just to get a feeling of what eats the most. But I haven't had time to set this up again.

[qualita]

In my experience, what has penalized me the most are queries like “give me the emails of the day”, where it ends up fetching the entire email content. Maybe a good practice would be to only retrieve the Subject instead, so it doesn’t consume as many tokens.

[eirikb]

That's a good idea. Currently the server is kind of dumb, it is almost just a mapping of the Graph OpenAPI spec directly. Just with authentication. And trimming. Lots of trimming (since the spec JSON file is 45MB). Both in terms of picking out endpoints, but also in terms of trying to remove excessive stuff.
Meaning that we don't actually tell the LLM how it should behave, it just finds out this itself. I see a lot that the LLM tries to make the requests smaller, by selecting fields and limiting results. I would prefer that the LLM does this by itself without intervention by the server, but it might need a little nudge - could be a custom description is enough (this had been discussed before, but mostly because the current description from the spec is quite long).

Perhaps that would help a lot? A hint to the LLM we can define per tool/endpoint? Just a "Pro tip try to read subject first because content eats tokens"

[ctcanbol]

The OP marked as closed this but i think it's still a fact for the latest version. I think tips per tool/endpoint may help LLM's.

[eirikb]

The OP marked as closed this but i think it's still a fact for the latest version. I think tips per tool/endpoint may help LLM's.

Yes I agree.
We implemented https://github.com/toon-format/toon/ , as an experiment (can be added with --toon) - but this only helps with data, not with tools.
There is another quickfix that might help: tool discovery. Others have mentioned this before, and I've implemented it in other MCP servers, and it seems to work fine. Could be an option? It's not bullet proof though, and can cause weirdness and less quality.

Then there is going over the tools and see if we should improve overridden schemas or do other types of trimming.