RAP2 MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity. The tools cover different aspects of RAP2 API interaction: login/session management (debug_login_info, ensure_session, test_connection), interface retrieval by different criteria (by_id, repository_interfaces, search_by_keyword, search_by_path), and connection testing. No overlap exists between these functions.
Naming Consistency5/5
All tools follow a consistent 'rap2_' prefix with snake_case naming and clear verb_noun patterns (e.g., 'get_interface_by_id', 'search_interfaces_by_keyword'). The naming convention is uniform throughout the toolset, making it predictable and easy to understand.
Tool Count5/5
With 7 tools, this server is well-scoped for its purpose of interacting with RAP2 API. The count is appropriate, covering essential operations like authentication, interface retrieval, and search functionalities without being overwhelming or too sparse. Each tool earns its place in the workflow.
Completeness4/5
The toolset provides good coverage for core RAP2 API operations, including login/session management and interface retrieval/search. However, there are minor gaps in CRUD operations for interfaces (e.g., no create, update, or delete tools) and repository management, which agents might need to work around for full lifecycle coverage.
Average 3/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't describe what '详情' (details) includes, whether it's a read-only operation, if it requires authentication, or any error conditions. This leaves significant gaps in understanding the tool's behavior beyond the basic action.
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 without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what '接口详情' includes in the response, potential error cases, or dependencies on other tools like 'rap2_ensure_session'. For a tool with no structured behavioral data, more context is needed to guide effective use.
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%, with the parameter 'interfaceId' fully documented in the schema as '接口 ID（传入字符串，内部会规范化）'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage without adding value.
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 ('获取接口详情' - get interface details) and the resource ('根据接口 ID' - by interface ID), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'rap2_get_repository_interfaces' or 'rap2_search_interfaces_by_keyword', which also retrieve interface information but through different mechanisms.
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 like 'rap2_search_interfaces_by_keyword' or 'rap2_get_repository_interfaces'. It lacks context about prerequisites (e.g., whether a session is required) or exclusions, leaving the agent to infer usage from the tool name alone.
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 states it retrieves a list, implying a read-only operation, but doesn't specify whether it requires authentication, pagination behavior, rate limits, error conditions, or the format of the returned list. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
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 in Chinese that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to understand at a glance. Every part of the sentence contributes to clarifying the tool's function.
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 has no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't address behavioral aspects like authentication needs (implied by sibling tools), error handling, or the structure of the returned interface list. For a tool that likely interacts with a repository system, more context on usage and output is needed to be fully helpful.
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%, with the single parameter 'repositoryId' documented in the schema as '仓库 ID（传入字符串）' meaning 'repository ID (pass as string)'. The description doesn't add any additional meaning beyond this, such as where to find the ID or examples of valid values. Since the schema fully describes the parameter, the baseline score of 3 is appropriate.
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 ('获取' meaning 'get' or 'retrieve') and the resource ('仓库下的全部接口列表' meaning 'all interface lists under the repository'). It specifies the scope ('全部' meaning 'all') which helps distinguish it from sibling tools like rap2_get_interface_by_id (which gets a single interface) and rap2_search_interfaces_by_keyword/path (which search with filters). However, it doesn't explicitly differentiate from rap2_search_interfaces_by_keyword/path in terms of when to use one over the other.
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 prerequisites (e.g., whether authentication is needed, though sibling tools like rap2_ensure_session suggest session management), or compare it to sibling tools like rap2_search_interfaces_by_keyword/path for filtered searches. Usage is implied only by the tool name and description context.
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 full burden for behavioral disclosure. It only states the basic function without mentioning expected behavior like search scope (partial/full match), result format, pagination, error handling, or authentication requirements. For a search tool with zero annotation coverage, this leaves significant gaps in understanding how the tool actually behaves.
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 - a single Chinese sentence that efficiently communicates the core functionality. Every word earns its place: '按关键字搜索接口' establishes the primary action, and '（可选限定仓库）' adds the optional constraint without redundancy. No unnecessary elaboration or structural issues exist.
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 (search functionality with optional filtering), lack of annotations, and absence of output schema, the description is insufficiently complete. It doesn't explain what constitutes an 'interface' in this context, how search results are returned, what happens when no matches are found, or any limitations/constraints. The agent would need to guess about important behavioral aspects.
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 mentions both parameters ('关键字搜索接口' and '可选限定仓库'), which aligns with the 100% schema description coverage. However, it doesn't add meaningful semantic context beyond what's already in the schema descriptions ('搜索关键字' and '仓库 ID（可选）'). With complete schema coverage, the baseline is 3, and the description doesn't provide additional value like search algorithm details or repository relationship context.
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: '按关键字搜索接口' (search interfaces by keyword) with optional repository limitation. It specifies both the verb ('搜索' - search) and resource ('接口' - interfaces), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'rap2_search_interfaces_by_path' or 'rap2_get_repository_interfaces', 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 minimal guidance: it mentions the optional repository limitation but doesn't specify when to use this tool versus alternatives like 'rap2_search_interfaces_by_path' (path-based search) or 'rap2_get_repository_interfaces' (repository-specific listing). No explicit when-not-to-use scenarios or prerequisites are mentioned, leaving the agent with insufficient context for optimal tool selection.
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 full burden for behavioral disclosure but offers almost none. It doesn't describe what 'search' entails (e.g., exact match, partial match, case sensitivity), what the output looks like, pagination behavior, error conditions, or authentication requirements. The description merely restates the tool name with slight elaboration, failing to compensate for the lack of annotations.
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 extremely concise - a single sentence in Chinese that directly states the function. There's no wasted text or unnecessary elaboration. However, the brevity comes at the cost of completeness, as it lacks important contextual information that would help an agent use the tool effectively.
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 search tool with 2 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what constitutes a successful search, what format results return, how many results to expect, or error handling. The agent would struggle to understand the tool's behavior beyond the basic parameter requirements documented in the 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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no additional meaning beyond what's in the schema - it mentions 'request path' and 'optional repository limitation' which are already covered by parameter descriptions. This meets the baseline for high schema coverage where the description doesn't need to compensate.
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 as 'search interfaces by request path' with optional repository limitation. It specifies both the verb ('search') and resource ('interfaces'), making the function understandable. However, it doesn't explicitly differentiate from sibling tools like 'rap2_search_interfaces_by_keyword' which suggests similar search functionality with different parameters.
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 minimal guidance, only mentioning the optional repository limitation. It doesn't indicate when to use this tool versus alternatives like 'rap2_search_interfaces_by_keyword' or 'rap2_get_repository_interfaces', nor does it specify prerequisites, success conditions, or error scenarios. The agent receives no contextual decision-making help.
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 full burden for behavioral disclosure. It states the tool debugs login environment configuration and doesn't return plaintext passwords, which is useful context about security behavior. However, it doesn't disclose other traits like whether it's read-only, requires authentication, has rate limits, or what the output format looks like. The description adds some value but leaves significant gaps.
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 clearly states the tool's purpose and a key behavioral constraint (no plaintext passwords). It's front-loaded with essential information and has zero wasted words, making it highly concise and well-structured.
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 has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It explains what the tool does and a security constraint, but for a debugging tool, it could provide more context about what 'debug' entails (e.g., returns configuration details, error messages) or when it's useful. The lack of output schema means the description doesn't explain return values, which is a gap.
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 0 parameters, and schema description coverage is 100%. With no parameters to document, the baseline is 4. The description doesn't need to add parameter semantics, and it appropriately focuses on the tool's purpose without unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose is to debug current login environment configuration without returning plaintext passwords. This is clear about what it does (debug configuration) but doesn't specify how it differs from sibling tools like rap2_ensure_session or rap2_test_connection, which also relate to authentication/connection. The purpose is understandable but lacks 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 doesn't mention when it should be used (e.g., for troubleshooting login issues) or when not to use it, nor does it reference sibling tools like rap2_ensure_session or rap2_test_connection. There's implied usage for debugging, but no explicit context or exclusions.
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. It mentions logging in and saving cookies to a session cache, but lacks details on authentication requirements, error handling, rate limits, or what happens if a session already exists. This is a significant gap for a login tool with zero 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 in Chinese that directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded with the core action.
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 complexity of a login tool with no annotations and no output schema, the description is incomplete. It doesn't explain the return values, error conditions, or behavioral traits like session management. This leaves gaps for an AI agent to understand how to use it effectively.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description implies environment parameters are used for login, which adds context beyond the empty schema, though it doesn't specify what those parameters are. Baseline is 4 for zero parameters.
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: '使用环境参数登录并保存 Cookie 到会话缓存' (Login using environment parameters and save cookies to session cache). It specifies the verb (login) and resource (session cache), though it doesn't explicitly differentiate from sibling tools like 'rap2_debug_login_info' which might have overlapping functionality.
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 using environment parameters for login, but doesn't specify scenarios, prerequisites, or exclusions compared to siblings like 'rap2_debug_login_info' or 'rap2_test_connection'.
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 key behaviors: probing a specific endpoint, automatic login if necessary, and example prompts for use. However, it lacks details on error handling, response format, or any rate limits or permissions required. The description adds some context but doesn't fully compensate for the absence of annotations, leaving gaps in understanding the tool's operational 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 concise and front-loaded, stating the core action in the first clause. It includes useful example prompts without unnecessary elaboration. However, the inclusion of Chinese prompts might reduce clarity for non-Chinese speakers, and the structure could be slightly improved by separating the action from the usage hints more clearly.
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 (involving connection testing and automatic login), no annotations, no output schema, and 0 parameters, the description is moderately complete. It covers the what and how but lacks details on return values, error cases, or how it differs from siblings. For a tool with potential side effects (like automatic login), more behavioral context would be beneficial to ensure safe and correct usage by an AI agent.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's action and context. This aligns with the baseline expectation for tools with no parameters, where the description should not waste space on non-existent inputs.
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: testing connection and validating session by probing /repository/joined, with automatic login if needed. It uses specific verbs ('测试连接并校验会话', '探测', '自动登录') and identifies the resource ('/repository/joined'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like rap2_ensure_session, which might have overlapping functionality.
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 context through example prompts ('测试rap连接', '确保已登录'), suggesting this tool is for verifying connectivity and session status. However, it doesn't provide explicit guidance on when to use this versus alternatives like rap2_ensure_session or rap2_debug_login_info, nor does it specify prerequisites or exclusions. The usage is implied but not clearly articulated.
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:

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

Score Badge

Copy to your README.md:

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

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