Logs and Diagnostics

When you run into situations like "the service shows as normal but the client still reports errors" or "the tool list looks fine but actual calls fail," the logs page is usually the most direct entry point for diagnosis.

Its importance lies in the fact that most AI clients do not fully expose the actual MCP call process to you. Without logs and diagnostics, you can only guess.

MCP2Skill treats logging as a standalone capability precisely to fill this blind spot.

The Two Types of Information on the Logs Page

The current version is mainly divided into two categories:

• Call logs
• Service logs

They serve different purposes and are best used together.

What This Page Is Best at Answering

• Whether a configuration change actually took effect
• Whether a failure was a client issue, a service issue, or an authorization issue
• Whether a particular MCP has been persistently unstable recently
• Who is making calls, when errors started, and whether errors keep recurring

Call Logs

Call logs are best for answering:

• Which call failed
• When the failure occurred
• Which service, workspace, or client triggered it
• What the request and response roughly looked like

If you have just finished verifying a client integration, look here first.

Service Logs

Service logs are best for answering:

• What the backend has been outputting recently
• Whether a particular error keeps recurring
• Whether background actions such as startup, connections, authentication, and cleanup are working normally

When troubleshooting remote connections, service startup, or API Key issues, service logs are usually very valuable.

What to Focus on in Call Logs

After selecting a call, focus on:

• Whether the call succeeded
• Which service or workspace was the target
• Whether the response time is abnormal
• Whether there is a clear error message

If you can immediately tell it is an authentication or connection issue, going back to the corresponding service details page or settings page to fix it is more efficient than retrying blindly.

How to Search Service Logs

If there are a lot of logs, search directly by keyword, for example:

• The service name
• error
• oauth
• gateway
• unauthorized

This helps you narrow things down faster.

Downloading and Clearing Logs

The current version supports:

• Downloading the current log file
• Clearing service logs
• Controlling the call log retention count in settings
• Clearing all logs on the data management page

Before formal troubleshooting, if you plan to hand the logs to someone else for analysis, it is safer to download a copy first and then clear them.

A Common Troubleshooting Path

When you see a client error, work through the following steps in order:

1. Check the recent call records on the logs page
2. Open the failure details to confirm the direction of the error
3. Switch to the service logs and search for related keywords
4. Return to the corresponding service, workspace, or settings page to fix the configuration
5. Make another real call to verify

When to Look at Workspace Logs vs. Global Logs

• To see what has recently happened in a specific workspace: go to the logs tab on that workspace's details page
• To troubleshoot globally: go straight to the main logs page

The two entry points do not conflict and can be used together.

Related Chapters

• To see overall trends: see Dashboard and Statistics
• To adjust the log retention policy: see General and MCP Settings
• To review common failure scenarios: see FAQ and Troubleshooting