token-context-mcp

by MCK564

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Each tool targets a distinct capability—repo enumeration, context maps, symbol lookup, impact slices, index freshness, imports, FTS search, file skeletons, and symbol packets—though find_symbols/search_source and get_impact_slice/get_module_dependents sit close enough that an agent may need careful descriptions. Overall boundaries are clear and the descriptions reinforce purpose.
Naming Consistency4/5
The set mostly follows a get_<object> pattern with list_repositories, find_symbols, and search_source as reasonable verb variations. All names are snake_case and consistently place the action before the object, creating a predictable surface.
Tool Count5/5
Nine tools is appropriate for a token-context indexing server: each tool covers a distinct aspect of repository context without redundancy. The count feels neither thin nor overloaded.
Completeness4/5
The surface covers the full workflow: list available repositories, fetch orientation maps, search for symbols and source text, inspect imports and file skeletons, check index freshness, and retrieve bounded context packets. A raw full-file read tool is intentionally absent given the bounded-context purpose, but this is a reasonable design choice rather than a gap.
Average 3.5/5 across 9 of 9 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses useful behavioral details: it returns 'IDs and spans' and restricts results to source-backed symbols, never arbitrary files. However, it does not address pagination, limit behavior, pattern semantics, or side effects, leaving meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences with no filler, and the core scoping is front-loaded. It earns points for efficiency, though the brevity comes at the expense of deeper guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no annotations, no output schema, and a list of close sibling tools, the description is too sparse. It omits parameter semantics, usage guidance, and return-format details beyond 'IDs and spans,' making it barely adequate for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only clarifies the pattern parameter as a name or qualified-name fragment. The other five parameters, including kind, limit, profile, and max_tokens, are left entirely undocumented, and no information is given about valid kind values or how limit behaves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Find'), a clear resource ('source-backed symbols'), and the matching criterion ('by name or qualified-name fragment'). It also adds a scoping contrast ('never arbitrary files'), which helps separate it from file-level search, though it does not explicitly name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as search_source or get_symbol_context. The phrase 'source-backed symbols' implies symbol lookup rather than text search, but the agent is left to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the result is bounded, that graph edges are 'observed', and that original source may be needed for body/freshness/ambiguity, signaling possible truncation or staleness. It does not mention side effects, authentication needs, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with the primary action front-loaded and a short conditional instruction. There is no filler or redundancy, though the jargon could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, two sentences are insufficient. It does not explain what a source packet contains, what graph edges are returned, how depth/max_tokens/profile affect results, or what include_body and include_omitted_ids control.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter-level guidance. The seven parameters—depth, profile, max_tokens, include_body, include_omitted_ids, repo_id, and symbol_id—are not explained beyond their self-explanatory names, and key behaviors like depth limits, token limits, and omitted IDs are left unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: return a bounded source packet around one indexed symbol and observed graph edges. This is clearer than a tautology, though 'source packet' and 'observed graph edges' are jargon and it does not explicitly distinguish from graph-related siblings like get_impact_slice or get_repo_map.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence provides a useful exclusion: use original source when body, freshness, or ambiguity matter, implying the returned context may be derived, stale, or incomplete. However, it does not say when to prefer this tool over alternatives like find_symbols or search_source, so the guidance is only partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does provide meaningful behavior: Tree-sitter extraction, lexical scope, and dynamic-import flagging. It still omits output shape, whether the result is direct or transitive, and what 'indexed' implies operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the core operation front-loaded and the key limitation in the second sentence. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations, no output schema, and 0% parameter documentation leave significant gaps: return format, relationship to sibling impact/symbol tools, selection semantics when both path and module are provided, and error/indexing requirements. The description covers only the core behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only clarifies that path or module selects a single indexed entity. It does not explain profile, max_tokens, or how repo_id is used, leaving most parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action—'Return Tree-sitter-extracted lexical import relationships'—for a clear resource ('one indexed path or module') and distinguishes itself from semantic resolution and call-graph inference. It does not explicitly name a sibling tool, so differentiation is conceptual rather than direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only, lexical-use context and warns that dynamic imports are flagged rather than resolved, which suggests it is not for semantic dependency analysis. However, it never names sibling tools like get_impact_slice or gives explicit when-to-use/when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses that edges are 'observed' and that the result is a candidate slice, not proof of full blast radius, which is valuable honesty about limitations. However, it does not mention whether the operation is read-only, what the output shape is, or how budget-related parameters affect behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action is front-loaded, and the second sentence adds an important scoping caveat without repeating schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with seven parameters, no annotations, and no output schema, this description is not complete enough for confident invocation. An agent would need to guess the meaning of most optional parameters and the expected return structure, so significant context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it explains almost nothing about the parameters. It connects 'symbol' to the likely symbol_id usage, yet does not clarify direction, depth, max_nodes, max_tokens, or profile, all of which are non-obvious from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('traverse') and resource ('observed caller/callee edges from a symbol'), making the core function immediately clear. It distinguishes itself from siblings by framing the result as an impact slice rather than a proof or a generic symbol lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus siblings like get_module_dependents or get_symbol_context. The caveat that it is 'never a proof of complete blast radius' implies a limitation, but it does not tell the agent when to prefer this tool or what alternative to use for stronger evidence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure itself. It does disclose one important behavior—function bodies are elided by default—and notes the file must be indexed, but it does not mention side effects, accessibility requirements, or behavior for missing/unindexed files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences; the main capability is front-loaded and the elision default is added as a precise second sentence. No filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, no output schema, and no annotations, the description is too thin. It leaves 'source-backed headers' undefined, omits return-shape details, and does not clarify how max_tokens/profile/include_private affect results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate, but it only loosely clarifies that the path is repository-relative and indexed. The optional parameters profile, max_tokens, and include_private are not explained anywhere, leaving their semantics to inference from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Return') and resource ('imports and source-backed headers from one indexed repository-relative file'), making the tool's scope clear. It also distinguishes itself from sibling tools like get_repo_map or find_symbols by emphasizing a single-file skeleton rather than repo-wide mapping or symbol search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use when you need a file's imports and headers rather than full bodies. However, it does not state when to prefer this over siblings such as get_symbol_context or get_impact_slice, and it gives no explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal the FTS5 mechanism, the bounded nature of snippets, and the return contents. However, it does not state whether the operation is read-only, whether an index must exist beforehand, or how limits such as max_tokens affect the results beyond the vague term 'bounded'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every phrase earns its place by specifying scope, mechanism, and return values: 'indexed symbol bodies', 'FTS5', 'bounded source snipets, symbol IDs and line evidence'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It gives a clear core purpose but omits parameter semantics, tool-selection guidance relative to find_symbols, and any behavioral caveats or result-shaping details, leaving an agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the five parameters. It hints that 'query' is an FTS5 query but does not clarify repo_id, limit, profile, or max_tokens. The agent cannot reliably infer parameter semantics from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'Search', a precise resource 'indexed symbol bodies', the mechanism 'FTS5', and the expected outputs 'bounded source snippets, symbol IDs and line evidence'. This clearly distinguishes it from siblings like find_symbols, which likely focuses on symbols rather than source bodies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to search inside symbol source bodies, but it gives no explicit when-to-use guidance, exclusions, or comparisons with sibling tools such as find_symbols or get_symbol_context. The usage context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description itself must disclose behavior. It indicates a read-only operation ('Return') and implies salientness checking, but it doesn't describe error conditions or what 'active snapshot' means. This is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no redundant wording, with the primary operation front-loaded. The usage guidance is separated into its own sentence, improving readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description gives the gist of the return (snapshot metadata and changed paths) but not its structure or field details. It also doesn't elaborate on 'active snapshot,' so an agent may need to call the tool to learn the output shape. Given the single parameter and low complexity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description never mentions the repo_id parameter, and with 0% schema description coverage, it adds no semantic value beyond the parameter name. The name is somewhat self-explanatory for an index-status tool, but the description still doesn't confirm its role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and names the resource 'active snapshot metadata and paths changed since indexing,' which clearly differentiates it from sibling code-graph tools. The second sentence adds a functional context (run before graph results), reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells when to run the tool ('Run before relying on graph results'), giving agents a clear trigger condition. It doesn't name alternatives or state when not to use it, but the timing guidance is concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral-disclosure burden. It discloses a 'bounded context budget', describes the compact entry shape, and warns that results are not proof of full coverage. It does not mention permissions or error behavior, but for a read-oriented map tool the main behavioral caveat is clearly conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences front-load the primary purpose, then provide the output format, the format switch, and the key caveat. There is no filler, no restating of the title, and every clause adds functional value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema and no annotations, the description is not fully complete: it leaves query and profile semantics undefined and does not enumerate all return fields. But it provides enough for a basic call with repo_id, explains the compact/full output difference, and gives a necessary truncation caveat, so it is minimally viable rather than severely deficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate for the bare parameter names. It does explain format values and indirectly hints at budget_tokens, and sources repo_id from list_repositories. However, query, profile, include_tests, and include_omitted_ids are not semantically described, leaving most of the 7 parameters underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening verb 'Return' plus object 'ranked definitions' and scope 'for a repo_id from list_repositories' states exactly what the tool does and ties it to its prerequisite data source. The closing caveat 'Use for orientation, not proof of full coverage' helps distinguish this from deeper lookup siblings. It is specific and resource-scoped, not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use for orientation, not proof of full coverage' gives a clear context for when this tool is appropriate, and 'request format="full" for signatures, per-symbol evidence, and detailed rank_basis' tells the agent how to get more detail. It does not explicitly name sibling alternatives such as find_symbols or search_source, so it lacks the explicit exclusion needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It discloses an important behavioral trait: roots are never exposed. However, it does not explicitly state whether the operation is read-only, what the output format is beyond IDs, or whether any authorization is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core purpose is front-loaded, and the usage hint follows immediately. Every word contributes to the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description communicates the essential behavior: return repository IDs and avoid exposing roots. The 'call this first' guidance completes the practical context, though the exact response shape is implied rather than explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so there is no parameter semantics to convey. The baseline for a zero-parameter tool is 4, and the description adds no contradictory or confusing parameter-related information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('registered repository IDs'), and the word 'only' sharpens the scope. This clearly distinguishes it from the sibling tools, which operate on repository contents rather than just enumerating IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Call this first' gives explicit sequencing guidance, and 'roots are never exposed' warns the agent about a limitation. It does not name sibling alternatives explicitly, but the first-step positioning plus the ID-only scope makes the usage context reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![token-context-mcp MCP server](https://glama.ai/mcp/servers/MCK564/token-context-mcp/badges/card.svg)](https://glama.ai/mcp/servers/MCK564/token-context-mcp)

Score Badge

Copy to your README.md:

[![token-context-mcp MCP server](https://glama.ai/mcp/servers/MCK564/token-context-mcp/badges/score.svg)](https://glama.ai/mcp/servers/MCK564/token-context-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MCK564/token-context-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server