RCP-1

Server Quality Checklist

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

Latest release: v0.9.27
Disambiguation5/5
Each tool has a clearly distinct purpose: SAPRead for raw source, SAPSearch for object names, SAPNavigate for code navigation, SAPTransport for transport management, SAPLint for static analysis, SAPDiagnose for diagnostics, SAPContext for understanding, and SAPManage for system capabilities. No overlap in functionality.
Naming Consistency5/5
All tool names follow a consistent 'SAP' prefix plus a descriptive verb/noun (Read, Search, Navigate, Transport, Lint, Diagnose, Context, Manage), maintaining a uniform pattern.
Tool Count5/5
With 8 tools, the set is well-scoped for an SAP ABAP development environment, covering reading, searching, navigation, transport, linting, diagnostics, context analysis, and system management without being overwhelming.
Completeness3/5
The tools cover analysis and management well, but lack a direct tool for writing or modifying ABAP objects (e.g., SAPWrite). While SAPTransport and SAPManage handle some writes, the absence of code-writing capabilities is a notable gap for a development-oriented server.
Average 4.6/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=true. The description confirms this by listing mutating actions (create_package, delete_package, FLP write, set_api_state) and notes that mutating actions require 'writable safety config and write scope in authenticated mode.' This adds context beyond annotations without contradiction.
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 somewhat verbose but well-structured with a clear high-level statement followed by bullet points for actions. Every sentence adds value, though it could be slightly more concise.
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 complex tool with 23 parameters, nested objects, and no output schema, the description covers major actions, prerequisites, and return format (features + systemType). It explains 'available: false' as a guard for dependent operations. However, it lacks full output schema details.
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 description coverage is 100%, so baseline is 3. The description adds value by explaining defaults for apiState and contract, and context for object types. It does not detail every parameter but provides meaningful guidance for key parameters.
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 'Probe and report SAP system capabilities' and enumerates specific actions (features, probe, cache_stats, package lifecycle, FLP management, set_api_state). It distinguishes from sibling tools like SAPRead and SAPSearch by focusing on management and probe actions.
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 explicitly advises using the features action before operations depending on optional features. It also outlines when to use each action (e.g., package lifecycle for DEVC, FLP actions for tiles, set_api_state for API contracts). However, it does not provide explicit when-not-to-use 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?
Annotations show readOnlyHint: false and destructiveHint: false, and the description adds context by noting that lint_and_fix returns fixed source, format calls SAP, and set_formatter_settings is blocked read-only. It does not fully detail side effects (e.g., whether lint_and_fix persists changes), but the information is largely adequate.
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 with a clear opening sentence and a bullet-style enumeration of actions. It is concise for the amount of information conveyed, though slightly dense.
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 6-parameter input schema and no output schema, the description covers all actions, local vs remote behavior, parameter requirements, and hints to sibling tools (SAPDiagnose). It is fully complete for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters. The description adds value by naming actions and their prerequisites (e.g., 'source' needed for lint/format but not list_rules), but this is supplementary rather than essential.
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 starts with 'Run local abaplint rules on ABAP/CDS source' and enumerates six specific actions (lint, lint_and_fix, etc.), clearly stating what the tool does. It distinguishes from sibling tools like SAPDiagnose by mentioning 'For ATC/syntax/unit tests use SAPDiagnose.'
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 each action (e.g., 'format: pretty-print via SAP's ADT formatter (needs source)') and when not to ('For ATC/syntax/unit tests use SAPDiagnose'). It also clarifies which actions run locally vs remotely, providing clear context for selection.
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?
The description adds significant behavioral context beyond the readOnlyHint annotation. It explains the scope-based API for references, the format for objectType filtering (ADT slash type), the default and max for maxResults, and that hierarchy returns specific relationships. There is no contradiction with 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 information-dense and front-loaded with the main actions. It is slightly long but every sentence serves a purpose. Minor improvement could be more structured formatting, but it is concise enough.
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 complexity (9 parameters, 4 actions) and no output schema, the description covers the main scenarios and parameter usage. It lacks details on return format and error handling, but the schema descriptions and the behavioral context provided are sufficient for an agent to use the tool 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?
Schema coverage is 100%, but the description adds meaningful context: for references, it explains the scope-based API and the objectType filter format; for hierarchy, it clarifies return types; it also describes the alternative object identification (uri vs name+type). This adds value beyond the schema 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 that the tool navigates code for definitions, references, completion, and hierarchy. It provides specific details for each action: references uses the scope-based Where-Used API with line numbers, snippets, and package; hierarchy returns superclass, interfaces, and subclasses. It also contrasts with SAPContext for CDS objects, effectively distinguishing it from siblings.
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 gives explicit guidance on when to use references vs hierarchy and when to prefer SAPContext for CDS impact analysis. It also explains alternative ways to specify objects (uri vs type+name). However, it does not provide when-not-to-use guidance for other actions or list alternatives for definition and completion.
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?
Annotations already declare readOnlyHint=true. The description adds value by detailing behavioral traits like returning compressed contracts, filtering SAP standard objects, and providing impact analysis buckets. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a heading, bullet points, and a footer. While dense, it is front-loaded with purpose and decision rules. Every sentence adds value, though it could be slightly more 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?
Given the complexity (12 parameters, 4 actions), the description thoroughly covers all aspects including each action's return type (impact buckets, deps contracts) and parameter usage. It references a docs page for full detail, ensuring 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?
Schema coverage is 100%, providing baseline semantics. The description adds significant context for each action's parameters and their use cases (e.g., 'impact: CDS blast-radius' with detailed bucket classification), surpassing the schema's 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 it's the primary tool for understanding ABAP/CDS objects, with specific verbs like 'returns intent' and 'use instead of SAPRead'. It differentiates from siblings by providing distinct actions (impact, deps, structure, usages) and explicitly contrasts with SAPRead.
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 gives explicit decision rules for picking actions based on user questions (e.g., 'What breaks if I change <CDS>?' → impact). It also advises when to use alternatives (e.g., 'For non-CDS reverse-lookup use SAPNavigate') and when to use before editing.
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?
The description fully discloses behavioral traits beyond annotations. It details destructive actions (delete, release, remove_object) with sub-options (recursive, removeLockedObjects), explains create's inference of transport type, and notes read-only actions (history, layers, targets). No contradiction with annotations (destructiveHint=true).
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 efficient and front-loaded, immediately stating the tool's purpose and actions. While long, every sentence adds value. Could be slightly more structured (e.g., bulletized actions), but it remains clear and concise for the complexity.
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's complexity (16 parameters, 11 actions, no output schema), the description is complete. It covers actions, parameters, prerequisites (e.g., for target), side effects (e.g., delete with removeLockedObjects), and error conditions. It also mentions response characteristics for key actions (e.g., 'The response reports the resolved transport target' for create).
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 description coverage is 100%, but the description adds significant context beyond the schema. For example, it explains the 'target' parameter's forms and restrictions, and notes that the 'action' parameter's description includes behavioral details for each value. Baseline 3; extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as managing CTS transport requests (SE09/SE10). It lists 11 specific actions, each with a distinct verb and resource. The sibling tools (SAPRead, SAPSearch, etc.) are different in scope, making this tool well-differentiated.
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 explicit guidance for each action, including when to use each (e.g., 'list: show transports (defaults to current user, modifiable only)') and context like using summary=true for cheaper list operations. It does not explicitly state when not to use this tool, but the distinct sibling tools make it clear. Minor omission: no direct comparison to 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?
The description discloses many behavioral traits beyond the readOnlyHint annotation, such as caching behavior with force_refresh, token-efficient grep, and how version parameter works with drafts. It also explains limitations like on-prem only types and truncated packages. No contradictions with annotations.
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 very long (600+ words) and dense with details. While it is well-structured and front-loads the purpose, it could be more concise. However, for the complexity of the tool, the length is justified.
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 complexity (23 parameters, many object types, no output schema), the description is remarkably complete. It covers all major behaviors, parameter combinations, and edge cases (e.g., deprecated aliases).
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?
With 100% schema coverage, baseline is 3. The description adds meaning by explaining interactions between parameters (e.g., method vs include for CLAS, grep vs method) and providing usage examples, which goes beyond the schema 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's purpose: 'Read SAP ABAP objects — exact raw source, a method body, grep output, inactive drafts, revision history, or metadata.' It uses specific verbs and resources, and distinguishes from sibling tools like SAPContext by recommending it for intent-level context.
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 provides explicit guidance on when to use this tool versus alternatives, e.g., 'prefer SAPContext first (intent-level context before raw source).' It also advises on token-saving strategies for CLAS (method="*" or grep) and explains on-prem only types.
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?
The description clearly discloses behavioral traits beyond the annotations: it marks read-only actions (e.g., cds_testcases, atc_variants, object_state, dumps, traces, etc.) and write-scope actions (trace_start, trace_cancel). It also details side effects (e.g., trace_start defaults to HTTP, SQL on) and limitations ('needs allowDataPreview'). No contradiction with 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 long but well-structured: a one-line summary, a bullet list of actions with concise descriptions, and a brief workflow reference. It front-loads the overall purpose. Minor redundancy exists (e.g., repeating 'read-only' for multiple actions), but it remains efficient for the tool's complexity.
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's complexity (35 parameters, 20 actions, multiple workflows), the description covers all actions, their parameters, and contextual behavior. It includes a workflow example for quickfixes and a link to full reference. The lack of an output schema is mitigated by action-specific return descriptions (e.g., 'returns ETags/hashes/divergence flags').
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?
With 100% schema coverage, the schema already describes all parameters. The description adds substantial value by explaining action-specific usage, default behaviors, and relationships (e.g., 'id' for dumps/traces; 'Omit to list, provide to get details'). It also clarifies parameter dependencies like 'proposalUserContent: pass through exactly'.
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 begins with a clear verb+resource statement: 'Run diagnostics on ABAP objects and analyze runtime errors.' It then enumerates 20 distinct actions, each with a specific purpose. This distinguishes SAPDiagnose from siblings like SAPRead, SAPSearch, etc., which handle other concerns.
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 provides explicit usage guidance for each sub-action, including preconditions (e.g., 'optional source = pre-write dry-run, nothing written'), the workflow for quickfixes, and constraints like 'read-only' flags. It also references a full action reference page. While it doesn't explicitly contrast with siblings, the guidance is thorough and actionable.
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?
Descriptions of modes and parameter behavior (e.g., BOR objects appear as SOBJ, source parameter options for tadir_lookup) add behavioral context beyond the readOnlyHint annotation. No contradictions; all described behaviors are read-only.
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?
Very concise yet comprehensive. Uses numbered modes and tips. Every sentence adds value; no redundant or irrelevant content. Front-loaded with main purpose and then details.
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 complex tool with 7 optional parameters and no output schema, the description sufficiently explains usage modes, parameter interdependencies, and return field semantics (uri, objectType). Refers to other tools for further actions, ensuring an agent can use it correctly.
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%, so baseline is 3. The description adds valuable context: explains how query parameter applies to both modes, restrictions on source parameter, and relationships between objectType and objectTypes for different search modes. This goes beyond schema descriptions but does not cover every edge case.
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?
Clearly states the tool searches for ABAP objects, exact TADIR entries, or source code. Distinguishes between object search and tadir_lookup modes, and explicitly contrasts with sibling tools like SAPQuery and SAPRead.
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?
Provides explicit when-to-use guidance: object search for name patterns, tadir_lookup for exact cross-package lookup. Advises preferring tadir_lookup over long SAPQuery IN-lists. Also references alternatives for field name searches (SAPRead, SAPQuery).
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:

[![abap-mcp-rcp-v1 MCP server](https://glama.ai/mcp/servers/dhruvmahendrapatel/abap-mcp-rcp-v1/badges/card.svg)](https://glama.ai/mcp/servers/dhruvmahendrapatel/abap-mcp-rcp-v1)

Score Badge

Copy to your README.md:

[![abap-mcp-rcp-v1 MCP server](https://glama.ai/mcp/servers/dhruvmahendrapatel/abap-mcp-rcp-v1/badges/score.svg)](https://glama.ai/mcp/servers/dhruvmahendrapatel/abap-mcp-rcp-v1)

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/dhruvmahendrapatel/abap-mcp-rcp-v1'

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