Claude Session MCP

by TimEvans

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
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: checking context budget, retrieving session history, getting session state, recommending context resets, and syncing planning documents. The descriptions clearly differentiate their functions, making misselection unlikely.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (check_context_budget, get_session_history, get_session_state, sync_planning_doc), but 'should_reset_context' deviates slightly by using 'should' instead of a direct action verb. Overall, the naming is readable and predictable with only minor inconsistency.
Tool Count5/5
With 5 tools, this server is well-scoped for session management and context tracking. Each tool serves a specific, necessary function in this domain, and the count is neither too thin nor excessive for the apparent purpose.
Completeness4/5
The tool set covers core session management needs: monitoring context usage, tracking history and state, providing reset recommendations, and updating planning documents. A minor gap exists in direct context reset or modification tools, but agents can work around this using existing tools like 'should_reset_context' for guidance.
Average 3.2/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/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 states the tool 'analyzes' and provides a 'recommendation', implying a read-only, non-destructive operation, but doesn't clarify output format, potential side effects, or error handling. For a tool with zero annotation coverage, this is insufficient to inform the agent adequately about its behavior.
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 concise and front-loaded, stating the core purpose in the first sentence. It efficiently lists analysis criteria without unnecessary elaboration. However, it could be slightly more structured by explicitly separating the recommendation output from the analysis inputs, but overall, it avoids waste and is appropriately sized.
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 the tool's complexity (involving multiple analysis factors) and the absence of annotations and output schema, the description is incomplete. It doesn't explain what the recommendation output looks like (e.g., boolean, score, rationale), how the analysis is performed, or any limitations. For a tool with no structured output information, this leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with one optional parameter ('working_directory') well-documented in the schema. The description adds no parameter-specific information beyond what the schema provides, such as how 'working_directory' influences the analysis. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 clearly states the tool's purpose: 'Get intelligent recommendation on whether to reset context.' It specifies the verb ('get recommendation') and the resource ('reset context'), and mentions the analysis criteria (context usage, todo completion, git state, session duration). However, it doesn't explicitly differentiate from sibling tools like 'check_context_budget' or 'get_session_state', which might overlap in monitoring context-related metrics.
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?
The description provides no guidance on when to use this tool versus alternatives. It mentions what the tool analyzes but doesn't specify scenarios for invocation, prerequisites, or comparisons to siblings like 'check_context_budget' or 'get_session_history'. This lack of contextual usage information leaves the agent without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a mutation tool ('Update'), but doesn't disclose permissions needed, whether changes are reversible, rate limits, or what happens to the planning documents. The description mentions what can be done but not the behavioral implications.
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 appropriately concise with two sentences that efficiently convey the tool's purpose and capabilities. It's front-loaded with the main action and resource, followed by specific operations. No wasted words or redundant 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 mutation tool with 7 parameters and no annotations or output schema, the description is insufficient. It doesn't explain the expected outcome format, error conditions, or how the different modes affect the planning documents. The agent would need to guess about the tool's behavior and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions, so it meets the baseline for high schema coverage.
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 clearly states the action ('Update') and target resource ('.context/dev/{branch}/ planning documents'), and specifies three specific operations (append to progress log, update active work, mark tasks complete). However, it doesn't differentiate this tool from sibling tools, which appear unrelated to planning document management.
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?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or contextual triggers. It lists three modes but doesn't explain when each mode is appropriate or how they relate to different planning scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. While it implies a read-only operation ('get'), it doesn't specify whether this requires permissions, how data is formatted or returned, if there are rate limits, or what happens with errors. For a tool with zero annotation coverage, this is a significant gap in behavioral context.
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, efficient sentence that directly states the tool's purpose with specific examples. It's front-loaded with the core function and avoids unnecessary words, making it easy for an agent to parse quickly.
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?
Given the tool's moderate complexity (retrieving session history) and the absence of annotations and output schema, the description is minimally adequate. It covers what data is retrieved but lacks details on return format, error handling, or behavioral traits. With no output schema, the agent must infer return values from the description alone, which is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the input schema already documents the single parameter 'working_directory' with its type and default. The description adds no additional parameter information beyond what the schema provides, such as examples or edge cases. Baseline 3 is appropriate when the schema handles parameter documentation adequately.
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 clearly states the tool's purpose: to retrieve session history including completed todos, files modified, tool calls, and git commits. It specifies the verb 'get' and the resource 'session history' with concrete examples of what's included. However, it doesn't explicitly differentiate from sibling tools like 'get_session_state' or 'check_context_budget', which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate, when not to use it, or how it differs from sibling tools such as 'get_session_state' or 'should_reset_context'. This leaves the agent without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 describes what the tool returns (a snapshot of session state) but lacks details on behavioral traits such as whether it's read-only, if it requires specific permissions, how it handles errors, or if there are rate limits. This is a significant gap for a tool with no annotation coverage.
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, efficient sentence that front-loads the key information ('Get unified snapshot of current session state') and lists specific components without unnecessary details. It is appropriately sized and has zero waste, making it easy for an agent to parse quickly.
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?
Given the tool's complexity (a state snapshot tool with one optional parameter), no annotations, and no output schema, the description is moderately complete. It specifies what the snapshot includes, but lacks details on output format, behavioral context, or usage guidelines. This is adequate as a minimum viable description but has clear gaps in providing full context for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with one optional parameter ('working_directory') fully documented in the schema. The description does not add any meaning beyond the schema, as it does not mention parameters or their semantics. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('unified snapshot of current session state'), listing key components like todos, git status, context files, and session info. However, it does not explicitly differentiate from sibling tools like 'get_session_history' or 'check_context_budget', which might also involve session-related data, leaving some ambiguity in sibling differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context for usage, such as when a snapshot is needed, or refer to sibling tools like 'get_session_history' for historical data or 'check_context_budget' for budget checks, leaving the agent without explicit usage instructions.
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 provided, the description carries the full burden of behavioral disclosure. It describes the tool as a read-only check operation and details the return values (tokens used, remaining, etc.), which is helpful. However, it lacks information on potential side effects, error conditions, or performance characteristics, leaving gaps in behavioral understanding for a tool with no annotation support.
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 extremely concise and front-loaded, consisting of two sentences that efficiently convey the tool's purpose and return values without any wasted words. Every sentence earns its place by providing essential information, making it easy for an agent to parse and understand quickly.
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?
Given the tool's low complexity (one optional parameter, no output schema, no annotations), the description is reasonably complete. It explains what the tool does and what it returns, which is sufficient for basic usage. However, the lack of output schema means the description could benefit from more detail on return formats or examples, slightly limiting completeness.
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?
The input schema has 100% description coverage, documenting the single optional parameter (context_limit) with its type, default, and purpose. The description does not add parameter details beyond the schema, but with only one optional parameter and high schema coverage, this is acceptable. The baseline is 3, but the simplicity and full schema coverage justify a 4.
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 clearly states the tool's purpose with specific verbs ('check', 'returns') and resources ('context window usage and remaining capacity'), distinguishing it from siblings like get_session_history or sync_planning_doc. It explicitly lists what information is returned (tokens used, remaining, percentage, status), making the purpose unambiguous and distinct.
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?
The description provides no guidance on when to use this tool versus alternatives or in what context it should be invoked. It does not mention prerequisites, timing, or comparisons to sibling tools like should_reset_context, leaving the agent to infer usage based solely on the purpose statement.
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:

[![ccsession MCP server](https://glama.ai/mcp/servers/TimEvans/ccsession/badges/card.svg)](https://glama.ai/mcp/servers/TimEvans/ccsession)

Score Badge

Copy to your README.md:

[![ccsession MCP server](https://glama.ai/mcp/servers/TimEvans/ccsession/badges/score.svg)](https://glama.ai/mcp/servers/TimEvans/ccsession)

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/TimEvans/ccsession'

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