cc98-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct function: downloading, browsing boards, reading posts, user info, hot topics, listing boards, new topics, search, and status. No overlap in purpose.
Naming Consistency4/5
All tools start with 'cc98_' and mostly follow a verb_noun pattern (e.g., cc98_get_posts, cc98_search_topics). Minor inconsistency with cc98_hot_topics (adjective_noun) and cc98_status (noun only), but overall clear.
Tool Count5/5
10 tools is well-scoped for a forum reader: covers browsing, searching, reading, downloading, and status checking. Neither too few nor too many.
Completeness2/5
The tool set is read-only; missing create, update, delete operations for posts, topics, replies, or user interaction. Significant gap for full forum support.
Average 3.9/5 across 10 of 10 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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 fully convey behavioral traits. It only states the purpose and does not disclose whether the tool is read-only, requires authentication, supports pagination, or any side effects. This is a significant gap for a tool that likely performs a network fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the purpose. However, it contains no structure (e.g., sections, examples) and is too minimal to be considered well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, two parameters with 0% coverage, and the tool's complexity (fetching topics with pagination), the description fails to explain return format, pagination behavior, or any side effects. It is highly incomplete.
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%, meaning the input schema lacks parameter descriptions. The tool description does not mention the parameters ('from' and 'size') or their semantics (e.g., pagination offset and limit), leaving the agent with no guidance beyond the schema field names.
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 retrieves the latest posted topics site-wide ('获取全站最新发布的主题帖'). It uses a specific verb ('获取' - get) and resource ('最新发布的主题帖' - latest posted topics), distinguishing it from siblings like cc98_hot_topics (hot topics) and cc98_search_topics (search).
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 lacks explicit context or exclusions, such as noting that this tool is for unfiltered site-wide latest topics while cc98_get_board_topics filters by board.
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 must disclose behavioral details. It only states the operation and a parameter effect. It does not mention read-only nature, pagination, sorting, or side effects.
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—one sentence that covers the core functionality. No redundant phrases.
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?
The description is insufficient for a tool with 4 parameters, no output schema, and pagination. It omits return format, default behavior, and error handling.
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 description adds meaning for the 'best' parameter (filter for best posts). Schema coverage is 50%, and the description does not cover 'from' or 'size' parameters beyond their schema defaults.
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 retrieves a list of topic posts for a specific board, and mentions the 'best' parameter. However, it does not explicitly differentiate from sibling tools like cc98_hot_topics or cc98_new_topics.
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 guidance on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusion cases.
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?
无注解，描述仅说明检查状态，未披露任何行为特性（如是否只读、有无副作用、输出格式）。对于无参数工具，仍缺少对返回结果的说明。
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?
单句描述，简洁明了，关键信息前置，无冗余。
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?
无参数，无输出模式，描述仅说明用途和何时调用，但未说明返回结果的形式（如布尔值、状态消息），对于简单工具尚可，但可更完整。
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?
无参数，模式覆盖度100%，描述无需补充参数信息，基线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?
明确说明检查 CC98 连接状态（网络和登录），与兄弟工具（如下载、获取帖子等）区分明显，定位为连接诊断工具。
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?
描述指出排查连接问题时先调用此工具，给出了明确的何时使用场景，但未提及何时不使用或替代方案。
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 full burden. It discloses the download action, return of save path, and the key constraint about preserving original files. However, it does not discuss overwrite behavior, error handling, or permission requirements.
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 concise, with the main action stated first followed by necessary context. Every sentence adds value, and there is no redundancy or filler.
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 no output schema, the description adequately explains the return value (save path). It covers the essential behavioral note about file preservation. Could optionally mention error behavior, but overall sufficient for a download tool.
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 100% with descriptions for url, dir, and filename. The description adds meaning by stating the source of the url (from placeholders) and the important preservation requirement. This goes beyond what the schema provides.
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 downloads images/attachments from CC98 posts to local folders, specifying the source (url from placeholders) and return value (save path). It distinguishes itself from siblings like cc98_get_image (which retrieves image content) and other tools focused on topics/users.
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 explains that the url comes from post content placeholders and includes an important directive about keeping original files. However, it does not explicitly state when to use this tool vs alternatives or any prerequisites, leaving room for ambiguity.
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 bears full responsibility. It states that the tool returns the image binary ('图片本体的') that can be viewed directly. However, it does not disclose whether the operation is read-only or any other behavioral traits (e.g., permissions, rate limits). The information is correct but minimal.
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, each contributing essential information: the first declares purpose, the second explains input source and output format. No redundant or extraneous text. The description 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?
For a simple tool with one parameter and no output schema, the description covers purpose, input source, and return type. It lacks details like error conditions or image format, but given low complexity, it is largely complete. The return type is explained despite missing output schema.
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 coverage is 100% as the only parameter 'url' is described in the schema with '图片地址（来自帖子内容中的 [图片: …]）'. The description reiterates this source, adding some extra context but not significant new semantic meaning. Baseline of 3 applies since schema covers the parameter 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?
The description specifies the verb '下载并查看' (download and view) and the resource '图片' (image), clearly stating the tool's function. It explicitly ties the URL source to cc98_get_posts output, distinguishing it from sibling tools like cc98_get_posts which retrieve post text with image placeholders.
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 a clear prerequisite: the url parameter must come from the [图片: …] placeholder in cc98_get_posts output. This gives explicit context on when to use the tool. It does not list alternative tools or exclusions, but the guidance is adequate for the simple use case.
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 should disclose behavioral traits. It only states the function and parameter meaning, but does not mention whether the operation is read-only, authentication requirements, or rate limits.
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, well-structured sentence that front-loads the main purpose and efficiently explains the parameter options without redundant 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?
For a simple tool with one parameter and no output schema, the description covers the main functionality and parameter meaning well. However, it does not describe the return format, which could help the agent anticipate the output.
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 description adds significant meaning to the 'range' parameter by explaining each enum value (today='今日十大', etc.), which is missing from the schema. With 0% schema description coverage, the description fully compensates.
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 gets CC98 hot topics and explains each range value (today, weekly, monthly, history). It distinguishes from siblings like cc98_get_board_topics and cc98_search_topics by focusing on hot topics.
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 context by listing time ranges, but does not explicitly state when to use this tool vs. alternatives or provide exclusion 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?
No annotations are provided, so the description carries full burden. It describes the basic operation but does not disclose any behavioral traits such as authentication requirements, rate limits, or destructive potential. The description is adequate but lacks depth.
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 concise with two sentences, front-loads the purpose, and contains no extraneous information. Every sentence earns its place.
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?
Despite no output schema or annotations, the description clearly explains what the tool does and what it returns (list of topics with fields). It also provides a follow-up instruction, making it complete for a search tool with three parameters.
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 for all parameters, so the schema already documents them. The description adds no additional parameter-level information beyond the schema, resulting in a baseline score.
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 performs a global search in CC98 forum for topics, returns a list with specific fields, and mentions a follow-up tool to read content. This distinguishes it from sibling tools like cc98_get_board_topics (likely board-specific) and cc98_hot_topics.
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 when to use the tool ('全站搜索') and explicitly directs the agent to use cc98_get_posts for reading content, providing clear context. However, it does not explicitly state when not to use it or name specific 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?
没有注解，描述承担行为披露责任。说明是查询操作（只读），返回资料和最近发帖，但未提及返回数据的数量、格式、分页等细节。行为基本透明，但缺乏深度。
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?
描述仅一句话，中文表达简洁，先说明功能再说明参数要求，信息密度高，无冗余。
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?
工具简单（2个可选参数），无输出模式。描述告知返回公开资料和最近发帖，足以让代理理解基本行为。未说明最近发帖的数量或排序，但整体完整度足够。
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?
输入模式已对每个参数提供了描述（用户名精确匹配、用户ID）。描述额外强调了只需提供其中之一，这增加了参数间互斥关系的语义信息，超越了模式本身。
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?
描述明确说明了工具的功能：查询CC98用户的公开资料及其最近发帖，并指定需要提供user_id或name其中之一。与兄弟工具（如cc98_get_board_topics、cc98_get_posts）明显区分，目标清晰。
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?
描述了使用条件（提供user_id或name），但未明确说明何时不使用此工具或提及替代工具。尽管如此，使用场景明确，对于获取用户信息而言足够直接。
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 burden. It correctly indicates a read-only listing operation, which is non-destructive. Additional details about output format or size could improve transparency but are not critical.
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 sentence that is front-loaded with the action and concise, containing no unnecessary 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 no output schema, the description is sufficient. It also provides a useful hint about the board ID being usable with another tool, adding contextual 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 tool has zero parameters, so the description does not need to explain parameters. Baseline of 4 is appropriate as there is no need for additional semantics.
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 lists all sub-forums and boards of CC98, using a specific verb and resource. It also distinguishes itself from siblings by mentioning that board IDs can be used with cc98_get_board_topics.
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 obtaining board IDs for later use with cc98_get_board_topics. However, it does not explicitly state when not to use or provide alternatives, but the context is clear enough.
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?
The description discloses that output is plain text (UBB cleaned) and mentions pagination behavior via from. However, it does not discuss error handling, authentication, or rate limits. Given no annotations, it 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first front-loads the core purpose, the second provides additional usage details and sibling references. Every sentence is necessary and concise, with no wasted 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?
The description explains the tool's output format, pagination, and references for media, which is adequate for a tool with no output schema. However, it could further clarify the structure of returned data (e.g., array of posts). Overall, it provides a solid mental model.
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?
Though the schema already describes all three parameters (100% coverage), the description adds contextual meaning by explaining pagination (from=10,20) and clarifying that size is the number of floors. This goes beyond the schema's basic descriptions.
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 reads floor content of a topic post, specifies that UBB is cleaned to plain text, and notes that floor 1 is the main post. It distinguishes itself from siblings by referencing cc98_get_image and cc98_download for handling images and files within the content.
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?
The description explicitly tells when to use this tool (to read floor content) and when not to (for images/files, use other tools). It also provides pagination guidance with the from parameter, enhancing usability.
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:

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

Score Badge

Copy to your README.md:

[![cc98-mcp MCP server](https://glama.ai/mcp/servers/EviterLesRoses2/cc98-mcp/badges/score.svg)](https://glama.ai/mcp/servers/EviterLesRoses2/cc98-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/EviterLesRoses2/cc98-mcp'

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