mcp-test-stepfun

by AIddlx

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation1/5
Three tools (capture_screen, take_screenshot, get_screen_image) appear to do the same thing, and push_server_onetime and push_server_persistent are deprecated duplicates of push_server. This creates significant ambiguity, making it hard for an agent to choose the correct tool.
Naming Consistency2/5
Tool names use snake_case but verb choice is inconsistent: 'capture', 'take', 'get' are used interchangeably for similar actions. Additionally, 'validate_date' is an unrelated utility that breaks the device-management naming pattern.
Tool Count3/5
At 9 tools, the count is within a reasonable range, but several tools are redundant or deprecated, making the set feel padded. The effective number of distinct, useful tools is smaller, so the scope is borderline.
Completeness2/5
The device-management domain is partially covered (connect, info, screen capture), but there are missing lifecycle operations like disconnect or file transfer, plus an unrelated date validation tool. Deprecated tools are left in, indicating an incomplete cleanup and an unclear domain boundary.
Average 3/5 across 9 of 9 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral details such as side effects, permissions, or return values. The deprecation notice does not disclose anything about how the tool 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 concise sentence that immediately conveys its essential message. It is perfectly sized and front-loaded with the deprecation status and the alternative.
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?
For a deprecated tool, the description is adequate as a warning to avoid it and points to a replacement. However, it lacks any information about what the tool actually does, which might be needed if the agent still has to interact with it.
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?
The schema has one boolean parameter 'video' with zero description coverage, and the description makes no mention of it. The parameter's meaning is completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does. It only marks the tool as deprecated and directs to use push_server instead, providing no verb or resource for the tool's function.
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 says 'Use push_server instead,' providing a clear alternative and implicitly telling the agent not to use this deprecated tool. This is excellent usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only mentions deprecation but does not explain what happens on invocation (e.g., whether it still works, errors, or is read-only). This is insufficient for an agent to predict 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and well-structured with the [DEPRECATED] prefix. However, it is so brief that it under-specifies the tool's purpose and parameters, making it barely adequate.
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 deprecated tool, the presence of an alternative is helpful, but the description does not explain the tool's functionality, parameters, or return behavior. Given the lack of output schema and annotations, this is incomplete for safe agent use.
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?
The schema has one parameter 'video' with no description, and the description does not mention it. There is zero parameter documentation, so the agent has no guidance on the meaning or usage of the boolean flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it merely says it is deprecated and to use push_server. This gives no verb or resource, leaving the agent to infer functionality from the name and schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Use push_server instead,' which is a direct alternative recommendation. This makes it unambiguous that this tool should be avoided and provides a clear replacement.
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, and the description offers only a generic statement about capturing the screen. It does not disclose what the output is (e.g., image data, file path), potential side effects, or any permissions required. The behavioral information is minimal.
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 very short and free of filler, which is efficient. However, it is so minimal that it borders on under-specification, but for a simple tool it is still readable.
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 tool lacks an output schema and annotations, and the description does not explain return values or usage context. With several similar sibling tools, the description is incomplete for an agent to know when to invoke this specific tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'format' is defined in the schema with an enum and default, but the description does not mention it or explain its meaning. Since schema description coverage is 0%, the description should compensate, but it does not.
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 states a clear action ('Capture the screen') and resource ('the device'), which is specific. However, it does not differentiate from sibling tools such as take_screenshot and get_screen_image, which appear synonymous.
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 is provided on when to use this tool versus alternatives like take_screenshot or get_screen_image. The description gives no context on selection criteria 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?
With no annotations provided, the description must carry the burden of behavioral disclosure, but it only states the action. It does not disclose what happens with the screenshot (e.g., return path, base64, file saving), possible side effects, or any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, and the key verb and object are front-loaded. It is not as bloated as typical descriptions, though it is under-specified in content.
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 existence of closely related sibling tools and the absence of an output schema or annotations, the description is too thin to fully contextualize the tool's behavior. It does not clarify return values, file types, or how it differs from capture_screen/get_screen_image.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'format' parameter is described in the schema with an enum and default, making its syntactic meaning clear. However, the description provides no semantic context (e.g., why choose png over jpg), and with 0% schema description coverage, the description fails to compensate for the lack of parameter explanation.
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 action ('Take a screenshot') and target ('from the device'), so the purpose is understandable. However, it does not distinguish this tool from similar siblings like capture_screen or get_screen_image, which prevents a higher 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?
There is no guidance on when to use this tool versus the alternative capture tools. No context is given about prerequisites, platform support, or situations where one sibling would be more appropriate.
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 must carry the full burden of behavioral disclosure. It only states the operation and does not mention return format, side effects, permissions, or any other behavioral traits beyond the basic 'get' 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 sentence with no redundant words, directly stating the action. It is appropriately concise for a simple tool.
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 minimal: it lacks information about the output format, whether the image is returned as data or a reference, any prerequisites, and how it differs from sibling screenshot tools. Given no output schema or annotations, this is insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines one optional 'format' parameter with enum values 'jpg' and 'png', but the description does not mention it or explain when to use each format. With 0% schema description coverage, the description fails to compensate for the missing semantic guidance.
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 uses the specific verb 'Get' and resource 'current screen image from the device', clearly stating the action. However, it does not distinguish from sibling tools like capture_screen or take_screenshot, which likely serve similar purposes.
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 information on when to use this tool versus alternatives such as capture_screen or take_screenshot. No context, exclusions, or alternative mentions are given.
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 only mentions that connection auto-detects, but does not reveal whether the operation is read-only, establishes a persistent connection, has side effects, or requires prerequisites. This is a significant gap for a 'connect' 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 two sentences with no filler. It is front-loaded with the primary purpose and includes the most important nuance (auto-detection) without extraneous detail.
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 tool with no annotations, no output schema, and a 2-parameter schema, the description is too thin. It does not explain what 'connect' entails, how modes differ, success/error conditions, or how it relates to sibling tools like push_server or capture_screen. The agent would lack essential context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 50% (only device_id has a description, mode does not). The description's only param-related note ('Auto-detects if no device_id provided') essentially repeats the schema's description for device_id and adds no new meaning. It does not clarify the mode parameter or its enum values.
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 states 'Connect to a device' with a specific verb and resource, and adds the scope of auto-detection when no device_id is provided. This is clear and distinct from sibling tools like capture_screen or get_device_info, but it does not explicitly contrast with them.
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 phrase 'Auto-detects if no device_id provided' gives a hint about when this tool can be used without explicit identification, implying a default behavior. However, it does not explain when to choose this tool over alternatives or when to use different modes like usb vs wireless.
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 must disclose behavior. It states the validation rule but does not explain what the tool returns (e.g., boolean, error message) or what happens on invalid input. The agent is left unclear about the tool's output 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?
The description is two short sentences, front-loaded with the purpose and immediately followed by the critical format constraint. Every word contributes to the meaning; no redundancy or filler.
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 tool is simple with one parameter and no output schema, so the description should explain the return value/behavior. It does not, leaving a notable gap. The agent cannot predict what 'validate' actually outputs. The bare minimum is provided.
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% and the parameter description already states 'Date string in YYYY-MM-DD format.' The tool description repeats the same format constraint, adding no new meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Validate a date string.' It specifies the exact format requirement, which also differentiates it from any sibling tools that handle dates. The verb 'validate' is specific and the resource is clearly defined.
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: use this tool when you need to check if a date string is in YYYY-MM-DD format. However, it does not explicitly state when to use it versus alternatives, though no date-related sibling tools exist. There is no guidance on when to use it in a broader workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It discloses the USB prerequisite and auto-connect default, which is valuable, but omits other behavioral traits such as whether the server persists by default, side effects on existing servers, or the meaning of the persistent parameter. This is useful but incomplete.
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 consists of three short sentences, each adding distinct and relevant information: purpose, prerequisite, and default behavior. There is no fluff, repetition, or irrelevant detail, making it highly efficient.
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?
The tool has four parameters and an output schema, but the description omits any guidance on choosing between this and the sibling push_server variants (onetime/persistent). It also does not clarify the role of the persistent parameter, leaving the agent to infer. The core action is clear, but the sibling ambiguity prevents a higher score.
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 already describes all four boolean parameters with defaults and descriptions (100% coverage), so the schema does the heavy lifting. The description adds minimal additional meaning beyond the auto_connect default, which is not enough to raise the score above baseline.
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 uses a specific verb ('Deploy') and names a concrete resource ('scrcpy server') with its purpose ('for wireless control'), making the core action clear. It does not explicitly contrast with sibling tools like push_server_onetime or push_server_persistent, so it misses a small opportunity to differentiate, but remains distinct enough.
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 gives a clear prerequisite ('Requires USB first') and a default behavior ('Auto-connects by default'), which helps establish when the tool should be used. However, it does not explain when to prefer this tool over the sibling variants (onetime vs persistent) or provide explicit exclusions, leaving the agent to infer.
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 the full transparency burden. It identifies the tool as a read operation ('Get device information') and lists specific data fields, which implies no side effects. However, it does not explicitly state safety, permissions, or any other behavioral traits, leaving some ambiguity.
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, concise sentence (10 words) that front-loads the core action and key data fields. It contains no redundant information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and an output schema present, the description is sufficiently complete. It states what information is retrieved, and since the output schema exists, it does not need to describe return values. No additional context is necessary.
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, and the schema confirms this with an empty properties object. The description does not need to elaborate on parameter semantics since there are none; the baseline score for 0 params is 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 with a specific verb 'Get' and resource 'device information', and lists distinct fields (name, battery, screen size). This effectively distinguishes it from sibling tools like capture_screen or connect_device, which target other aspects.
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 is given on when to use this tool instead of alternatives. The description does not mention any context, prerequisites, or comparisons to sibling tools, leaving the agent to infer usage solely from the tool name.
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:

[![mcp-test-stepfun MCP server](https://glama.ai/mcp/servers/AIddlx/mcp-test-stepfun/badges/card.svg)](https://glama.ai/mcp/servers/AIddlx/mcp-test-stepfun)

Score Badge

Copy to your README.md:

[![mcp-test-stepfun MCP server](https://glama.ai/mcp/servers/AIddlx/mcp-test-stepfun/badges/score.svg)](https://glama.ai/mcp/servers/AIddlx/mcp-test-stepfun)

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/AIddlx/mcp-test-stepfun'

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