What can you do with this server?

This server lets you create, configure, and invoke OpenServerless serverless API endpoints (actions) via the Model Context Protocol. * action_new: Scaffold a new action with a __main__.py and module file, optionally marking it as public or private. * action_invoke: Run an existing action with optional key=value parameters. * action_requirements: Add a Python library to an endpoint's requirements.txt (skips preinstalled libraries automatically). * action_add_secret: Wire a secret from .env into an endpoint's context as ctx. . * action_add_s3: Connect an endpoint to S3, providing ctx.S3_CLIENT, ctx.S3_DATA, ctx.S3_WEB, and ctx.S3_PUBLIC. * action_add_postgresql: Connect an endpoint to a PostgreSQL database via ctx.POSTGRESQL. * action_add_redis: Connect an endpoint to Redis, providing ctx.REDIS and ctx.REDIS_PREFIX. * action_add_milvus: Connect an endpoint to a Milvus vector database via ctx.MILVUS.

Which integrations are available for this server?

Adds Milvus vector database to an endpoint's context as ctx.MILVUS. Adds PostgreSQL database to an endpoint's context as ctx.POSTGRESQL. Adds Redis cache to an endpoint's context as ctx.REDIS and ctx.REDIS_PREFIX.

How do I use openserverless-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@openserverless-mcp create a new hello world endpoint" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

openserverless-mcp

Official

by apache

Overview Schema Related Servers Score Discussions

TypeScript

Local

openserverless mcp

An MCP server for OpenServerless. It exposes the OpenServerless action tools (previously the @opencode-ai/plugin tools under trustable-app/tools/) over the Model Context Protocol so any MCP-capable agent can drive them.

Tools

Tool	Description
`action_new`	Idempotently create an API endpoint (`__main__.py` + module file). `public` defaults to true.
`action_invoke`	Run `ops invoke <endpoint>` with `key=value` params and return the JSON result.
`action_requirements`	Add a library to an endpoint's `requirements.txt` (skips preinstalled libs).
`action_add_secret`	Wire a `.env` secret into an endpoint's context as `ctx.<SECRET>`.
`secret_status`	Check secret presence and endpoint bindings without reading its value.
`secret_bind`	Atomically bind the same secret to multiple endpoints.
`secret_unbind`	Atomically remove an obsolete generated binding without reading or deleting the secret.
`auth_setup`	Atomically wire Redis into all token-issuing, protected/session, and logout endpoints; never writes `.env` or configures JWT.
`action_add_s3`	Add bucket-scoped S3 to an endpoint's context (`ctx.S3_CLIENT`, `ctx.S3_DATA`, `ctx.S3_WEB`, `ctx.S3_PUBLIC`); forbids `list_buckets` and requires `put_object` → `get_object`/compare → `delete_object` for read/write verification.
`action_add_postgresql`	Add PostgreSQL (`ctx.POSTGRESQL`).
`action_add_redis`	Add Redis (`ctx.REDIS`, `ctx.REDIS_PREFIX`) and its Python runtime dependency; use it for opaque authenticated sessions.
`action_add_milvus`	Add Milvus vector DB (`ctx.MILVUS`).
`action_add_mongodb`	Add MongoDB (`ctx.MONGODB_CLIENT`, `ctx.MONGODB`).

The endpoint argument is either name (uses the v1 package) or package/name. Both segments must start with a letter and contain only letters, numbers, and hyphens. Use flat hyphenated names such as v1/employees-photo; underscores, spaces, nested routes, and forms such as v1/employees_photo or v1/employees/photo are invalid. Repeating action_new for a compatible existing endpoint is a successful check that leaves its files unchanged; incomplete paths and visibility conflicts are reported as MCP errors.

Secret values are never returned by these tools. Missing secrets and invalid endpoints are MCP errors (isError: true), so clients cannot mistake an incomplete binding for a successful tool call. action_add_secret remains as the single-endpoint compatibility tool; use secret_bind when several actions must share one user-configured credential.

Application .env and .env.production files are owned by Trustable's user-facing configuration flow. The MCP performs only value-free presence checks needed for binding validation and never creates, edits, imports, synchronizes, regenerates, or automatically populates those files. A missing variable must be added by the user through Trustable.

Application authentication uses Redis-backed opaque sessions. Create login, registration, me/session, every protected endpoint, and logout, then call auth_setup once with those complete endpoint sets. Store token-to-identity mappings under keys derived from ctx.REDIS_PREFIX with a bounded TTL; never use JWT or an application signing secret as a substitute.

Related MCP server: anyapi-mcp-server

Working directory

All path-based tools operate on paths relative to the process working directory: they read/write packages/<pkg>/<name>/... and .env. The server must therefore be launched with the user's app checkout as its CWD (this is how opencode launches type: "local" MCP servers).

Layout

src/
  index.ts            entrypoint — registers every tool over stdio
  lib.ts              shared helpers (endpoint parsing, connector injection, types)
  secrets.ts          secret name, .env, status, and atomic binding helpers
  tools/
    new.ts            action_new
    invoke.ts         action_invoke
    requirements.ts   action_requirements
    add-secret.ts     action_add_secret
    add-s3.ts         action_add_s3
    add-postgresql.ts action_add_postgresql
    add-redis.ts      action_add_redis
    add-milvus.ts     action_add_milvus
    add-mongodb.ts    action_add_mongodb
    secret-status.ts  secret_status
    secret-bind.ts    secret_bind
    secret-unbind.ts  secret_unbind
    auth-setup.ts     auth_setup

Each file under tools/ default-exports a Tool (defineTool({ name, config, handler })); index.ts imports them all and registers them in a loop. To add a tool, drop a file in tools/ and add it to the array in index.ts.

Run

Requires Node 18+ and ops on the PATH. TypeScript runs directly via tsx.

npm install
npm start          # tsx src/index.ts — speaks MCP over stdio

Wire into opencode

Add to the app's opencode.json:

{
  "mcp": {
    "openserverless": {
      "type": "local",
      "command": ["npx", "tsx", "/path/to/mcp/src/index.ts"],
      "enabled": true
    }
  }
}

Available Tools

8 tools

action_add_milvusB

Add Milvus vector DB connection to an endpoint's context. Provides ctx.MILVUS.

ParametersJSON Schema

Name	Required	Description	Default
`endpoint`	Yes	The endpoint path: 'name' (uses v1 package) or 'package/name'

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only says it adds a connection and provides ctx.MILVUS, but does not mention side effects, permissions needed, error behavior, or reversibility. This is insufficient for a mutation operation.

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 sentence, which is concise. However, it could be slightly expanded to include usage context without losing conciseness.

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 simple tool with one fully-covered parameter and no output schema, the description covers the essential purpose but lacks context on when and how to use it effectively.

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?

There is only one parameter with 100% schema coverage. The description provides no additional meaning beyond the schema's description of 'endpoint'. Since coverage is high, baseline 3 applies; no extra value added.

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 verb 'Add' and the resource 'Milvus vector DB connection' to an endpoint's context. It distinguishes itself from sibling tools like action_add_postgresql or action_add_redis by specifying Milvus.

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 (e.g., other action_add_* tools). There is no mention of prerequisites or scenarios where this tool should be avoided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

action_add_postgresqlC

Add PostgreSQL connection to an endpoint's context. Provides ctx.POSTGRESQL.

ParametersJSON Schema

Name	Required	Description	Default
`endpoint`	Yes	The endpoint path: 'name' (uses v1 package) or 'package/name'

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It implies a mutation (adding a connection) but discloses no side effects, requirements, or failure behavior.

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?

Two sentences, front-loaded with the main purpose. Each sentence adds value, but a bit more structure could improve clarity.

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 insufficient for an agent to understand how to use the connection or what 'ctx.POSTGRESQL' provides.

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 covers the endpoint parameter with a description. The tool description adds no additional meaning, so a 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 tool adds a PostgreSQL connection to an endpoint's context, differentiating it from sibling tools that add other types of connections. However, it does not elaborate on what the provided context object does.

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 or prerequisites. It only states the action without context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

action_add_redisB

Add Redis connection to an endpoint's context. Provides ctx.REDIS and ctx.REDIS_PREFIX.

ParametersJSON Schema

Name	Required	Description	Default
`endpoint`	Yes	The endpoint path: 'name' (uses v1 package) or 'package/name'

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description only states what is added, not behavioral aspects like overwrite behavior, prerequisites, or side effects. Minimal disclosure for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with action, no unnecessary words.

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 single parameter and no output schema, the description fails to explain state changes, error handling, or overwrite behavior. Incomplete for an addition 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 coverage is 100% with a clear description for the endpoint parameter. The description adds no new parameter semantics beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'Add' and resource 'Redis connection to an endpoint's context', and specifies the outcome (provides ctx.REDIS and ctx.REDIS_PREFIX). Distinguishes from sibling connection tools.

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?

Implies usage by name and description, but no explicit guidance on when to use versus alternatives (e.g., when adding Redis vs. other connections). Lacks exclusions or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

action_add_s3A

Add S3 connection to an endpoint's context. Provides ctx.S3_CLIENT, ctx.S3_DATA, ctx.S3_WEB, ctx.S3_PUBLIC.

ParametersJSON Schema

Name	Required	Description	Default
`endpoint`	Yes	The endpoint path: 'name' (uses v1 package) or 'package/name'

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It mentions the context variables provided but does not disclose side effects, idempotency, error conditions, or whether overwriting an existing connection is possible. This is adequate but not thorough.

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, front-loading the purpose and then listing the provided context variables. No wasted words; every sentence adds value.

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 low complexity (one parameter, no output schema), the description is complete enough. It explains the outcome (the context variables) without needing to detail return values. However, it could mention what happens if the endpoint already has the connection.

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% for the single parameter 'endpoint', with a clear description in the schema. The tool description does not add additional semantics beyond what the schema provides, so baseline score 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 adds an S3 connection to an endpoint's context, listing the specific context variables provided. It distinguishes itself from sibling tools like action_add_milvus and action_add_postgresql by being S3-specific.

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 when an S3 connection is needed, but does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or prerequisites. The context is clear but lacks guidance on when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

action_add_secretB

Add a secret to an endpoint's context. The secret must exist in .env.

ParametersJSON Schema

Name	Required	Description	Default
`secret`	Yes	The secret name (e.g. MY_SECRET)
`endpoint`	Yes	The endpoint path: 'name' (uses v1 package) or 'package/name'

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Only states addition and precondition; no disclosure of side effects, idempotency, or error 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?

Two short, direct sentences with no wasted words. Information is front-loaded.

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?

Adequate for a simple tool with 2 well-described params and no output schema. Lacks behavioral details like idempotency and error handling, but context signals indicate low complexity.

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% with clear parameter descriptions. The description adds the precondition (secret must exist in .env), which is useful but minimal beyond schema.

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?

Clearly states the verb 'Add a secret to an endpoint's context' and distinguishes from sibling tools that add different resources (e.g., S3, Redis). Could be more explicit about 'endpoint' but still specific.

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?

Implies usage by stating the secret must exist in .env, but no explicit when/when-not guidance or alternatives mentioned. Siblings are distinct, so confusion is low.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

action_invokeB

Invoke an API action. Executes ops action invoke with the given endpoint and key=value parameters.

ParametersJSON Schema

Name	Required	Description	Default
`params`	No	Key=value pairs to pass as parameters (e.g. ['key1=value1', 'key2=value2'])
`endpoint`	Yes	The endpoint path: 'package/action'

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits but only mentions execution via CLI. It does not indicate whether invocation is read-only or destructive, authentication needs, or side effects, leaving the agent uninformed.

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 sentence that is not verbose, but it could pack more relevant information without much expansion. It is efficient but lacks depth.

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 too terse for a tool with no output schema and no annotations. It fails to explain return values, synchronous vs asynchronous behavior, or error handling, leaving significant gaps for agent understanding.

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% with descriptions for both parameters. The description adds minimal value beyond the schema, merely restating 'endpoint and key=value parameters' and referencing the CLI command, which slightly contextualizes the parameter types.

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 invokes an API action by executing the underlying command `ops action invoke`, distinguishing it from sibling tools like `action_new` or `action_add_*` which are about creating or adding resources.

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 or what prerequisites are needed. It only states what it does without any context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

action_newA

Create a new API endpoint. Creates the action folder with main.py and module file.

ParametersJSON Schema

Name	Required	Description	Default
`public`	No	Whether the action is public (API endpoint). Defaults to true. Set false for private actions (e.g. init package).
`endpoint`	Yes	The endpoint path: 'name' (uses v1 package) or 'package/name'

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses file creation but does not mention permissions, idempotency, or what happens if the endpoint already exists. Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main purpose, no wasted words. Efficient and clear.

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?

No output schema, so description should hint at return values or errors; it does not. For a creation tool, knowing what is returned is useful. Adequate but not complete.

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%, so baseline is 3. Description adds no additional meaning beyond the schema's parameter descriptions. No value added.

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 creates a new API endpoint and specifies the exact files created (action folder, __main__.py, module file). It is distinct from sibling tools which add integrations or invoke actions.

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 for creating new endpoints but does not provide explicit when to use, when not to use, or alternatives. It's adequate but lacks guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

action_requirementsB

Add a library to an endpoint's requirements.txt. Skips if the library is preinstalled.

ParametersJSON Schema

Name	Required	Description	Default
`library`	Yes	The Python library name to add
`endpoint`	Yes	The endpoint path: 'name' (uses v1 package) or 'package/name'

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses one behavioral trait (skipping if the library is preinstalled), which is helpful. However, with no annotations available, it should also mention potential side effects, such as whether it creates the endpoint or modifies the file directly, or what happens if the endpoint doesn't exist. The disclosure is partial.

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: two sentences that convey the core action and a key behavioral condition. No filler or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (2 parameters, no output schema), the description covers the essential functionality. It lacks details on error handling or prerequisites, but for a straightforward add operation, it is reasonably complete.

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 includes descriptions for both parameters (library and endpoint), providing meaning. The tool description does not add additional parameter semantics beyond what the schema offers. With 100% schema coverage, a baseline 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 tool adds a library to an endpoint's requirements.txt, which is a specific action. It also mentions a conditional behavior (skips if preinstalled). However, it does not explicitly differentiate from sibling tools that add specific services (e.g., action_add_milvus), so it could be more precise about scope.

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 usage guidance is provided beyond the basic action. There is no indication of when to use this tool versus alternatives like action_add_postgresql or action_add_secret, nor conditions or prerequisites for using it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.1.0Jul 6, 2026
- First observedaction_add_milvus
- First observedaction_add_postgresql
- First observedaction_add_redis
- First observedaction_add_s3
- First observedaction_add_secret
- First observedaction_invoke
- First observedaction_new
- First observedaction_requirements

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool targets a unique purpose: adding specific connection types (Milvus, PostgreSQL, Redis, S3, secret), creating a new action, invoking an action, or adding a library requirement. There is no overlap in functionality, and the descriptions clearly distinguish each tool's role.

Naming Consistency4/5

All tools use a consistent 'action_' prefix and snake_case, but the verb structure varies: some include a noun after 'add' (e.g., action_add_milvus), while others lack a noun (action_invoke, action_new, action_requirements). This minor inconsistency prevents a perfect score, but the pattern is still predictable.

Tool Count5/5

With 8 tools, the set is well-scoped for a server focused on managing OpenServerless actions. It covers creation, invocation, dependency management, and integration with external services without being overwhelming or too sparse.

Completeness3/5

The tool surface covers core action creation and invocation, along with adding various connections and dependencies. However, it lacks tools for deleting, updating, or listing actions, as well as removing connections or secrets. These gaps could hinder agents needing full lifecycle management.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Tigris MCP ServerOAuth
dev.storage
Tigris MCP Server seamlessly connects AI agents to Tigris bucket and object management.
Cloud Storage Cloud Platforms File Systems
2
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21

Related MCP Servers

Fastn Serverofficial
Developer Tools App Automation Code Execution
fastn-ai
A
license
Not graded
quality
F
maintenance
An MCP server that enables dynamic tool registration and execution based on API definitions, providing seamless integration with services like Claude.ai and Cursor.ai.
Updated 3 months ago (2026-06-07 10:13 UTC)
23
MIT
anyapi-mcp-server
API Testing Developer Tools RAG Systems
quiloos39
A
license
Not graded
quality
D
maintenance
A universal MCP server that connects any REST API to AI assistants via OpenAPI or Postman specifications. It enables dynamic tool creation with GraphQL-style field selection and automatic schema inference for efficient data retrieval.
Updated 5 months ago (2026-04-13 18:26 UTC)
13
6
-
production-grade-mcp-agentic
Agent Orchestration AI & Machine Learning
FareedKhan-dev
A
license
Not graded
quality
D
maintenance
A production-grade MCP server designed for multi-tenant, authenticated, and observable AI agent systems, enabling secure tool execution across heterogeneous data sources.
Updated 5 months ago (2026-04-19 05:18 UTC)
62
MIT
Enterprise MCP Gateway and
Agent Orchestration Security
Devarinti9
A
license
Not graded
quality
D
maintenance
Enables AI agents to discover and execute tools via a secure MCP server with JWT authentication, RBAC, rate limiting, and audit logging.
Updated 3 months ago (2026-06-10 02:59 UTC)
1
MIT

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/apache/openserverless-mcp'

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

openserverless mcp

Tools

Working directory

Layout

Run

Wire into opencode

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Fastn Serverofficial

Latest Blog Posts

MCP directory API