Charles MCP Server

by tianhetonghua

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: v3.0.0
Disambiguation5/5
Each tool targets a distinct aspect of traffic capture/analysis: filter tools focus on different fields, checkpoint tools manage timelines, and utilities cover data retrieval, throttling, and summarization. The only pair (check_keyword_exists and filter_by_keyword) is clearly linked as a required sequence, avoiding ambiguity.
Naming Consistency4/5
All tools use snake_case. Filter tools consistently start with 'filter_by_', while others use verb_noun patterns (e.g., harvest_data, get_raw_data). This provides predictability, though not all follow the exact same template.
Tool Count5/5
13 tools cover the full lifecycle of traffic interception (harvest, checkpoint management, multiple filters, raw data retrieval, network throttling, and traffic summarization) without redundancy or unnecessary scope.
Completeness5/5
The tool surface enables full CRUD-like operations on captured traffic: harvest (create checkpoint), list/load checkpoints (read), filter by multiple criteria, get raw data, and analyze summaries. Throttling is also included, covering common debugging needs.
Average 4.4/5 across 13 of 13 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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 must disclose behavioral traits. It does not mention whether the tool is read-only, destructive, requires authentication, or has any side effects. It only describes the output structure, not the behavior of invoking the tool.
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 well-structured: a clear introductory sentence followed by bullet points that detail each field. It is appropriately sized for the tool's simplicity, with no redundant or missing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description fully explains all output fields and mentions the current_checkpoint_id annotation. It provides sufficient context for an agent to invoke the tool and interpret results.
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?
There are no input parameters (0 params), so the baseline is 4. The description adds value by explaining the meaning of each output field, which goes beyond the schema's field names. This helps the agent understand the return data.
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 lists all checkpoints to show the complete harvesting timeline, and enumerates the fields in each record. It distinguishes itself from sibling tools (like filter tools or harvest_data) by specifying it is for viewing checkpoint metadata, though it does not explicitly contrast with siblings.
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?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies a use case (viewing timeline), but does not mention alternatives or prerequisites. It is adequate for a simple list tool but lacks comparative guidance.
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 full burden. It discloses that the tool returns a 'simplified view' and specifies default and maximum limit values. However, it does not mention whether the operation is read-only, any side effects, or the exact nature of the simplified view. The behavioral disclosure is adequate but not exhaustive.
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 three sentences with no redundancy. The first sentence articulates the core function, the second provides use-case context, and the third specifies parameter behavior. Every sentence serves a purpose, and the structure is front-loaded and efficient.
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 simplicity (2 parameters, required 'status_code', and an output schema), the description covers the main points: purpose, usage scenario, and parameter details. It does not explicitly note that 'status_code' is required (though the schema does), nor does it describe the output format (but the output schema exists). Overall, it is sufficiently complete for a straightforward filter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the JSON schema provides no explanations for parameters. The description compensates fully by explaining the 'status_code' parameter with practical examples (403, 500) and detailing the 'limit' parameter's default (15) and maximum (50). This adds essential meaning beyond the schema.
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 function: filtering by HTTP status code and returning a simplified view. It also provides concrete examples (403, 500), making the purpose unambiguous. Among sibling tools that filter by other attributes, this tool is distinctively about status codes, so differentiation is clear.
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 offers usage context ('suitable for troubleshooting abnormal requests') and examples, but it does not explicitly state when not to use this tool or mention alternative sibling tools. The agent is left to infer that for host or keyword filtering, other tools should be used. No exclusionary guidance is provided.
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 provided, so description carries full burden. It discloses side effect (lifting batch limit for filter_by_keyword) and constraint (lightweight return, no body). This is good transparency for a simple tool, though could mention if it modifies state permanently.
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, front-loaded with purpose, minimal and no fluff. Every sentence adds value: purpose and behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with output schema (known but not displayed), description covers core purpose, return characteristics (lightweight), and side effect. Sufficient for agent to decide and invoke correctly.
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 0% so description must compensate. The description mentions the 'keyword' parameter implicitly (keyword to search for) but does not add format or constraints beyond schema. Adequate but not compensating fully.
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?
Description clearly states the tool checks if a keyword exists in the current checkpoint's entries, and explicitly distinguishes by promising only lightweight index (id + hit positions) without body content. This is specific and sets it apart from sibling tools like filter_by_keyword which presumably return more data.
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?
Description explains a key usage context: after calling this tool, the batch limit for filter_by_keyword on that keyword is lifted for 5 minutes. It also delineates return format. However, it does not explicitly state when not to use or list alternatives, missing full guidance.
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?
With no annotations, the description adds value by disclosing case-insensitivity, default limit (15), max limit (50), and that it returns the latest N items. However, it does not specify whether the operation is destructive or read-only, nor what 'streamlined view' means precisely.
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 with two sentences. It front-loads the core purpose and then adds key behavioral details. No redundant or unnecessary words.
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 that an output schema exists, the description doesn't need to detail return values. It covers essential behavioral aspects (case-insensitivity, limits) but does not explain how it differs from other filter tools or what constitutes a 'streamlined view'. Adequate for a simple filtering tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining the method parameter (HTTP methods) and the limit parameter (default 15, max 50, returns latest). This adds significant meaning beyond the raw schema.
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 action (filter by HTTP method) and the specific resource (HTTP methods like GET, POST, PUT, DELETE). It distinguishes from sibling filter tools by focusing on method filtering, and mentions a 'streamlined view' which sets expectations.
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 for filtering HTTP methods but does not provide explicit guidance on when to use this tool versus alternatives like filter_by_path or filter_by_status. No 'when not to use' or comparison with siblings.
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 provided, so the description carries the full burden. It discloses the search order (checkpoint then archive) and the scope of data returned (full raw data). It does not mention permissions, rate limits, or potential response size, but still provides useful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, search logic, and benefit. Efficient and front-loaded. No wasted words, though slight restructuring could improve flow.
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 an output schema exists (not shown but reported), the description need not cover return values. It explains the input parameter and search behavior, which is sufficient for a raw data retrieval tool. Could mention typical use cases or data size considerations.
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?
Only one parameter, entry_id, with no schema description. The description adds meaning by stating it is used to specify an entry and that the ID works across checkpoints. This compensates for the 0% schema coverage, though more detail on ID source could improve.
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 it retrieves complete raw data (headers, body, timing) for a specified entry. It distinguishes from sibling filtering and summary tools by focusing on raw retrieval across checkpoints.
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 description explains search priority (current checkpoint then ARCHIVE) and the ability to fetch historical data even after checkpoint switches. It does not explicitly state when not to use or list alternatives, but the context is clear given sibling tool names.
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 provided, so description must disclose behavior. It explains sorting by entropy and provides threshold ranges. Though it doesn't mention whether scanning is read-only or affects state, the description sufficiently informs about the tool's behavior (scanning + ordering).
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?
Three sentences, each packed with information: scanning & ordering, threshold meaning, limit bounds. No fluff. Front-loaded with main action.
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?
Output schema exists, so return values need not be described. Description covers threshold and limit defaults and semantics, addressing main parameters. Could mention that it scans all entries (performance note) but not required.
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?
Schema has 0% description coverage. Description adds semantic meaning: threshold default and entropy context, limit default and upper bound. This compensates well, though it could also explain parameter units or format.
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?
Description uses specific verb '扫描' (scan) and resource 'checkpoint 的所有条目' (all entries), explicitly stating the tool finds requests with encrypted/compressed/encoded body. It clearly distinguishes from sibling tools like filter_by_host, filter_by_keyword, etc., none of which target encryption.
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?
Purpose is clear enough for an agent to infer when to use it (detect encryption) and when not (other filter needs). However, no explicit when-not-to-use or alternative recommendations are given, leaving some ambiguity for new agents.
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?
With no annotations, the description discloses key traits: filtering action, simplified view, and limit behavior (default 15, max 50, returns latest N). It does not mention read-only status, but as a filter/query it is implied non-destructive. No contradictions.
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 succinct with three sentences, no wasted words, and front-loads the action. Every sentence provides essential information.
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 simplicity (2 params, no annotations) and presence of output schema, the description adequately covers purpose, usage, and parameter behavior. It could mention output format or pagination, but is largely complete for effective use.
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?
Schema coverage is 0%, so description must compensate. It explains path_keyword as URL path keyword with examples, and clarifies limit's default, maximum, and effect (returns latest N). This adds significant meaning beyond the raw schema.
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 filters by URL path keyword and returns a simplified view, with explicit examples like '/api/sign' and '/login'. This distinguishes it from sibling tools that filter by other criteria (e.g., host, method, status).
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 description indicates suitability for quickly locating a business interface, providing context for when to use. However, it does not explicitly say when not to use or name alternative tools, though the sibling context implies differentiation.
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?
With no annotations provided, the description carries full burden. It discloses that the operation is read-only, does not modify ARCHIVE/CHECKPOINTS, and that filtering tools work within the checkpoint's time window. This adequately informs the agent of key behavioral traits.
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 three sentences, efficiently conveying purpose, key constraints, and reversal option. It is front-loaded with the main action. Could be slightly more structured but very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and an existing output schema, the description covers all essential aspects: what it does, how to use it, its read-only nature, and how to switch back. It is complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter checkpoint_id has a description explaining it comes from list_checkpoints' id field. This adds value beyond the schema (which has no description), making it clear how to obtain the correct value.
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 switches CACHE to a specified checkpoint, enabling filtering tools within that time window. It distinguishes itself from sibling tools like harvest_data (revert to latest) and list_checkpoints (get checkpoint 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 description explains the context for using the tool: to load a checkpoint for read-only backtracking, and mentions that harvest_data() can be called to revert. It lacks explicit 'when not to use' but provides sufficient guidance for an agent.
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?
Discloses auto-cleanup behavior and provides a comprehensive list of presets. Without annotations, the description carries the full burden and does well, though it could mention potential impact on other operations.
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 structured with bullet points, clear sections, and no redundant information. It is concise yet fully informative.
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?
Covers usage, parameters, and behavior well. Although output schema exists but not described, the tool's action is simple (toggle throttling), so the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains the preset parameter thoroughly: valid values are preset names or null, and all preset names are listed. The compensation is complete.
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 it switches network bandwidth throttling, with preset enabling and null disabling. It distinguishes itself from sibling tools which are all filtering or data-related.
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?
Explicitly describes when to use preset vs null, and mentions auto-cleanup on process exit. No need to specify alternatives as siblings are unrelated.
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?
With no annotations, the description discloses key behaviors: returns simplified view, matches only top-level host, supports partial matching, and limit defaults/max. It does not specify read-only nature but is otherwise transparent.
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?
Five concise sentences with no wasted words. The purpose is front-loaded, and each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple filter tool with 2 params, the description covers filtering scope, matching behavior, output view, and limit constraints. An output schema exists but the description still sufficiently completes the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description fully explains both parameters: host_keyword (top-level host, partial matching) and limit (default 15, max 50, returns recent entries).
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 'Filter by host field, returning a simplified view.' It specifies the scope (top-level host only) and distinguishes from siblings like filter_by_keyword that might search all fields.
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 description implies usage for host-specific filtering and warns against mistaken matches in body/headers. However, it does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses side effects: writing to ARCHIVE, switching CACHE, clearing Charles session, and invalidating keyword auth. This is comprehensive and allows the agent to anticipate all behavioral impacts.
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 well-organized with sections and bullet points, making it easy to read. It could be slightly more concise, but the structure is effective for conveying detailed behavior.
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 that an output schema exists, the description appropriately focuses on behavior and side effects. It does not describe return values, but that is acceptable. The description covers all necessary usage context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but the description thoroughly explains the single boolean parameter 'fresh_start', detailing both default and alternative behaviors. This adds significant meaning beyond the schema's minimal definition.
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 syncs incremental traffic from Charles and creates a checkpoint. It distinguishes two modes (fresh_start=False/True) and explains their effects. This is specific and resource-oriented, differentiating it from sibling filtering tools.
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 description provides clear context for when to use the tool, including typical usage before switching analysis targets. However, it does not explicitly state when not to use it or compare to alternatives like load_checkpoint.
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 provided, so description bears full burden. It discloses return type (streamlined view with body preview), limit behavior, and unlock requirement. Could be slightly improved by noting error behavior if unlock is omitted, but overall well covered.
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?
Description is concise at three sentences, with purpose first, then usage guideline, then limit details. The internal reference '互锁-2' might be confusing to non-Chinese speakers but is minor. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and an output schema, the description covers purpose, usage guidance, parameter semantics, and special unlock condition. It is fully sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description adds all meaning. It explains the keyword parameter implicitly and the limit parameter with default and maximum. Also includes the unlock behavior tied to keyword. No parameter ambiguity remains.
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 returns a streamlined view of entries containing a keyword, including a body preview. It uses specific verb ('返回') and resource ('条目'), and the keyword condition distinguishes it from sibling filter tools like filter_by_status or filter_by_host.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the sibling tool check_keyword_exists as a prerequisite when match count exceeds 30, preventing context overflow. Also provides default and maximum limit values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behaviors: it does not fetch body, only routing dimensions, and lists exactly what statistics it returns. This provides complete transparency.
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 very concise: two sentences plus a bullet list. The first sentence states the main action, and the bullet list clarifies the dimensions. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema (mentioned in context), the description is complete. It explains the tool works on the current checkpoint and lists all output dimensions. No obvious gaps.
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?
There are 0 parameters, so baseline is 4. The description adds value beyond the empty schema by explaining the tool's purpose and output, which is necessary for an agent.
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 it performs global statistics on traffic for the current checkpoint, listing specific dimensions (top_hosts, top_paths, etc.). This distinguishes it from sibling filter tools, which focus on filtering rather than summarizing.
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 description implies when to use (for traffic overview) vs. siblings (filters), but lacks explicit guidance like 'use this instead of filter_by_* when you need aggregation.' Still, the purpose is clear enough for correct selection.
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:

[![Charles-mcp-server MCP server](https://glama.ai/mcp/servers/tianhetonghua/Charles-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/tianhetonghua/Charles-mcp-server)

Score Badge

Copy to your README.md:

[![Charles-mcp-server MCP server](https://glama.ai/mcp/servers/tianhetonghua/Charles-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/tianhetonghua/Charles-mcp-server)

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/tianhetonghua/Charles-mcp-server'

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