A
licenseA
qualityC
maintenanceEnables interaction with the AstroVisor API through MCP, automatically synced to the OpenAPI schema for dynamic tool discovery and execution.
6
32
5
MIT
ACOMO MCP Server
by progress-all
The ACOMO MCP Server provides comprehensive tools for interacting with the ACOMO API through a Model Context Protocol (MCP) server, enabling both API exploration and execution.
Core Capabilities:
API Documentation & Exploration: List available APIs (
list_apis), describe specific operations (describe_api), view schemas and components (api_schemas,list_components,describe_component), and generate request templates (generate_request_template)API Execution: Execute direct API calls (
call_api) with support for path parameters, query parameters, and request bodies (requiresACOMO_TENANT_IDandACOMO_ACCESS_TOKENauthentication)Health Monitoring: Perform server health checks (
healthtool)Guidance & Support: Access contextual guidance through the
acomo://guideresource andguideprompt to enhance AI interaction qualityFlexible Deployment: Run via Docker or locally with Node.js
The server supports complete API workflows from documentation discovery to schema exploration to actual API call execution, making it ideal for both development and integration scenarios.
Provides tools for interacting with acomo's API, enabling OpenAPI specification browsing, schema reference, request template generation, and direct API calls to manage acomo workflows and models
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@ACOMO MCP Serverlist all available APIs and show me their summaries"
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.
acomo-mcp-server
acomo API をツールから扱えるようにする MCP (Model Context Protocol) サーバです。stdio トランスポートで動作します。acomo の OpenAPI に基づく API 一覧やスキーマ参照、リクエスト雛形生成、API 呼び出し（問い合わせ）も行えます。
アーキテクチャ（MCP導入前/導入後）
以下は MCP 導入前と導入後のイメージ図です。
Related MCP server: Http-tools Universal MCP Server
このサーバが提供するツールの種類
acomo MCP は、用途に応じて次の2種類のツールを提供します。
OpenAPI仕様に基づくAPIドキュメント応答ツール（仕様の検索・要約・雛形生成・Q&A／APIコールは行わない）
list_apis,describe_api,api_schemas,generate_request_template,list_components,describe_component認証や追加設定は不要です。
OpenAPI仕様に基づくAPIコールツール（API を実行）
call_api認証のため環境変数
ACOMO_TENANT_IDとACOMO_ACCESS_TOKENの設定が必要です。
MCP クライアント設定例（推奨: Docker）
以下は mcpServers 設定です（API仕様ドキュメント応答用途の例）。
{
"mcpServers": {
"acomo": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"ghcr.io/progress-all/acomo-mcp-server:latest"
]
}
}
}latest イメージの更新（Docker）
latest タグのイメージを使っている場合、更新は次のコマンドで行えます。
docker pull ghcr.io/progress-all/acomo-mcp-server:latest注: 既に起動中のコンテナは自動では更新されません。pull 後は旧コンテナを停止・削除して、改めて起動してください。
OpenAPI仕様に基づくAPIコールに必要な追加環境変数（callApi）
APIコールツールを使う場合は、次の環境変数が必要です。
ACOMO_TENANT_IDACOMO_ACCESS_TOKEN
Docker の設定例（上の応答用途の例に追記する形）:
{
"mcpServers": {
"acomo": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "ACOMO_TENANT_ID=<tenant-id>",
"-e", "ACOMO_ACCESS_TOKEN=<access-token>",
"ghcr.io/progress-all/acomo-mcp-server:latest"
]
}
}
}代替: GitHub からクローンして実行する場合（APIコール例）
Node.js 18+（推奨: 20+）
リポジトリを取得してビルドします。
git clone https://github.com/progress-all/acomo-mcp-server.git cd acomo-mcp-server npm ci npm run buildmcpServers設定（Node 実行・OpenAPI仕様に基づくAPIコールの例）{ "mcpServers": { "acomo": { "command": "node", "args": ["/absolute/path/to/repo/dist/server.js"], "env": { "ACOMO_OPENAPI_PATH": "/absolute/path/to/repo/openapi.json", "ACOMO_TENANT_ID": "<tenant-id>", "ACOMO_ACCESS_TOKEN": "<access-token>" } } } }
提供ツール（Tools）
health: ヘルスチェックlist_apis: OpenAPI の API 一覧describe_api: 指定operationIdの詳細（method/path/summary/rawに加え、baseUrlExampleとcompleteUrlを含みます）api_schemas:parameters/requestBody/responsesの抜粋generate_request_template: パラメータ・ボディの雛形生成（pathParams/query/bodyのスケルトン）list_components:components.schemasの一覧describe_component: 指定スキーマの JSON Schemacall_api: 指定operationIdで API 呼び出し（必要に応じてpathParams/query/bodyを受け付けます）
提供プロンプト（Prompts）
guide: acomo の前提と MCP の使い方をまとめたガイドを、acomo://guideリソースとともに返します（クライアントが MCP Prompts に対応している場合に利用可能）。
提供リソース（Resources）
acomo://guide: acomo MCP ガイド: 開発の前提・認証・MCPの使い方の要点（text/markdown）
使い方
基本的な使い方（例）
acomo APIの詳細を知らなくとも自然文で問い合わせできます。以下は Cursorでacomoのモデル一覧を取得してと実行した場合の例です。これは実際にacomoのAPIコールまで実行しています。
開発中にacomo APIの詳細をAIに教えながらコーディングする場合はAPIコールなしでも使えます。以下は、Claude Codeでacomoのワークフローを開始する関数を書いてと実行した場合の例です。
MCP プロンプトの使い方（例）
guide プロンプトは acomo のコンセプトや前提をあらかじめ会話に読み込みます。単に自然文で問い合わせるよりも前提が揃った状態になるため、より高精度で一貫した回答を得やすく、毎回の前置き説明も不要になります。使い方はシンプルで、対応クライアントのプロンプト一覧から guide を実行するだけです（対応クライアントでは acomo://guide リソースも併せて表示されます）。
実行画面の例:
補足: 表示される応答や生成コードの品質は、LLM のモデル特性やプロンプト、提供したコンテキストにより最適化されます。acomo MCP は OpenAPI 仕様の参照と安全な API 実行を担う標準インターフェースであり、各 LLM の強みを最大限に活かせるよう設計されています。
ライセンス
MIT License. 詳細は LICENSE を参照してください。
環境変数
変数名 | 必須/任意 | 既定値 | 用途/期待される値 |
| APIコール時に必須 | なし | acomo テナントID。 |
| APIコール時に必須 | なし | Bearer アクセストークン。 |
| 任意 |
| API のベースURL（ドメインのみを指定してください。 |
| 任意 | 同梱 | 読み込む OpenAPI 仕様ファイルのパス。通常は変更不要。 |
| 任意 |
| リクエストタイムアウト（ミリ秒）。 |
参考
以下は、acomo 開発チームによる本 acomo MCP Server の開発背景と実装知見をまとめた技術ブログ記事です。
Available Tools
8 toolsapi_schemasAPI schemasC
operationIdからparameters/requestBody/responsesを抜粋
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| operationId | Yes |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions extraction of parameters/requestBody/responses, but doesn't specify what format the output is in (e.g., JSON, text), whether it's a read-only operation (implied but not stated), or any error conditions. The description adds minimal context beyond the basic action, leaving key behavioral traits unclear.
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 in Japanese that directly states the action. It's front-loaded with the core purpose and avoids unnecessary words. However, it could be more structured by explicitly naming the resource (e.g., 'from an API schema') for better clarity, but it's efficiently phrased.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (extracting API components), lack of annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain the output format, error handling, or how it relates to sibling tools like describe_api. For a tool that likely returns structured data about APIs, more context is needed to use it effectively.
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 has 1 parameter (operationId) with 0% description coverage, so the description must compensate. It mentions 'operationIdから' (from operationId), implying the parameter is an identifier for an API operation, but doesn't explain what operationId refers to (e.g., an OpenAPI operation ID, a specific endpoint), its format, or where to obtain it. This adds marginal meaning but insufficient for full understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'operationIdからparameters/requestBody/responsesを抜粋' (extract parameters/requestBody/responses from operationId) states a specific action (extract) and target (API components), but it's vague about what resource this operates on (API schemas? OpenAPI spec?) and doesn't distinguish from siblings like describe_api or describe_component. It provides a basic purpose but lacks specificity 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 guidance is provided on when to use this tool versus alternatives like describe_api or describe_component. The description implies extraction of specific API components, but there's no explicit context about prerequisites, when-not scenarios, or comparison to sibling tools. Usage is left to inference from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
call_apiCall APIC
operationIdを指定してAPIを呼び出す
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| operationId | Yes | ||
| pathParams | No | ||
| query | No |
TDQS
C2.1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states the basic action without mentioning authentication requirements, rate limits, error handling, side effects, or response format. For a tool that presumably makes external API calls, this lack of behavioral information is critically inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Japanese sentence that directly states the core action. There's no wasted language or unnecessary elaboration. While this conciseness comes at the cost of completeness, the structure is efficient and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 4 parameters, nested objects, no output schema, and no annotations, the description is completely inadequate. It doesn't explain what the tool returns, how to interpret results, what errors might occur, or any behavioral characteristics. The description fails to provide the necessary context for safe and effective 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?
With 0% schema description coverage and 4 parameters (body, operationId, pathParams, query), the description provides no information about any parameters. It mentions 'operationId' in the action but doesn't explain what it is, how to obtain valid values, or what the other parameters do. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'operationIdを指定してAPIを呼び出す' (specify operationId to call API) states the basic action but is vague about what resource it operates on and doesn't distinguish from siblings. It mentions 'API' generically rather than specifying what type of API or what the tool actually does with it. Compared to siblings like 'list_apis' or 'describe_api', it's unclear what makes this tool unique beyond the basic verb 'call'.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or exclusions. Given siblings like 'generate_request_template' and 'describe_api', there's no indication of when this direct call tool should be preferred over preparatory or descriptive tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_apiDescribe APIC
operationIdの詳細（paths/method/要約/原文）を返す
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| operationId | Yes |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns details but doesn't describe error handling, rate limits, authentication needs, or what happens if the operationId is invalid. This leaves significant gaps for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's apparent complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain return values, error cases, or behavioral traits needed for a tool that fetches API details, leaving the agent with insufficient context.
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?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'operationId' but doesn't explain its format, source, or constraints beyond what's implied. This adds minimal semantic value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns details about an operationId, including paths, methods, summaries, and original text, which gives a vague purpose. It specifies the resource (operationId details) but lacks a clear verb beyond 'returns' and doesn't differentiate from siblings like 'describe_component' or 'list_apis'.
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. It doesn't mention prerequisites, context for selecting it over siblings like 'list_apis' or 'describe_component', or any exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_componentDescribe componentC
指定schema名の詳細（JSON Schema）を返す
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions returning JSON Schema details but fails to describe error handling, rate limits, authentication needs, or what happens if the schema name is invalid. This leaves significant gaps in understanding the tool's 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 a single, efficient sentence that directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and low schema description coverage, the description is insufficient. It doesn't explain return values, error cases, or usage context relative to siblings, making it incomplete for effective agent use.
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 input schema has 1 parameter with 0% description coverage, and the description does not add any semantic details about the 'name' parameter. It doesn't explain what the name refers to, its format, or examples, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns detailed JSON Schema for a specified schema name, which clarifies the verb ('return') and resource ('detailed JSON Schema'). However, it doesn't differentiate from sibling tools like 'describe_api' or 'list_components', leaving ambiguity about when to use each. The purpose is clear but lacks sibling distinction.
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 such as 'describe_api' or 'list_components'. There are no explicit instructions on context, prerequisites, or exclusions, leaving the agent to infer usage based solely on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_request_templateGenerate API request templateC
operationIdからpath/query/body雛形を生成
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| operationId | Yes |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions generating templates but doesn't specify what the output looks like (e.g., format, structure), whether it's a read-only operation, or any constraints like rate limits. This leaves gaps in understanding the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Japanese, which is efficient. However, it lacks front-loading of key details and could be more structured to highlight purpose and usage. While not verbose, it under-specifies, making it less helpful than it could be with slightly more elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of generating API templates, no annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain the output format, error conditions, or how the tool interacts with siblings like 'list_apis.' For a tool that likely produces structured data, this leaves significant gaps in contextual understanding.
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 input schema has 1 parameter with 0% description coverage, so the description must compensate. It only mentions 'operationId' without explaining what it is, where to get it, or its expected format. This adds minimal meaning beyond the schema, failing to address the coverage gap adequately.
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 purpose: generating API request templates (path/query/body) from an operationId. It specifies the verb 'generate' and resource 'API request template,' though it doesn't explicitly differentiate from sibling tools like 'call_api' or 'describe_api.' The Japanese text is understandable but could be more precise about what '雛形' (template) entails.
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. It doesn't mention prerequisites, such as needing an operationId from another tool like 'list_apis' or 'describe_api,' or contrast with siblings like 'call_api' for actual execution. The description implies usage but offers no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthHealthB
acomo MCP server health check (fixed response)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that this is a health check with a 'fixed response', which implies it's a read-only operation that returns consistent output. However, it doesn't specify what the fixed response contains, rate limits, or authentication needs, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, front-loaded sentence that directly states the tool's function and key behavioral trait ('fixed response'). There is no wasted verbiage, making it efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally complete. It identifies the tool as a health check but lacks details on the response format or error conditions, which could be helpful for an agent despite the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter information, and its baseline score of 4 reflects this adequate coverage without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a 'health check' for the MCP server, which is a specific verb+resource combination. However, it doesn't differentiate this from sibling tools like 'describe_api' or 'list_apis' that might also provide server status information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over other sibling tools or what context triggers its use, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_apisList APIsB
acomoのAPI一覧を返す
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
B3.1/5.0
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 states what the tool does ('returns a list of APIs') without detailing behavioral traits such as whether it's read-only, if it requires authentication, rate limits, pagination, or error handling. For a tool with zero annotation coverage, this is a significant gap in 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?
The description is extremely concise—a single phrase in Japanese—and front-loaded with the core function. There's no wasted language, making it efficient for quick understanding. Every word earns its place by directly stating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for effective tool use. It doesn't explain what the returned list includes (e.g., API names, IDs, metadata), format (e.g., JSON array), or any behavioral context. For a tool with no structured data beyond the input schema, more detail is needed to ensure the agent can invoke 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate. A baseline of 4 is assigned since the schema fully handles parameters, and the description doesn't need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'acomoのAPI一覧を返す' (returns a list of APIs for acomo). It specifies the verb ('returns') and resource ('API list'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'describe_api' or 'api_schemas', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings such as 'describe_api' (likely for detailed API info) and 'api_schemas' (possibly for schema details), there's no indication of context, prerequisites, or exclusions for using 'list_apis'. This lack of comparative guidance limits its utility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_componentsList componentsB
acomoのAPIスキーマ（components.schemas）の一覧を返す
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
B3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a list but doesn't describe the format, pagination, rate limits, authentication needs, or potential errors. For a tool with zero annotation coverage, this is a significant gap in transparency about how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, though it could be slightly more structured for clarity (e.g., by adding context about usage).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple list operation) but lack of annotations and output schema, the description is incomplete. It doesn't explain what the returned list contains (e.g., format, fields) or any behavioral aspects like error handling. For a tool with no structured data beyond the input schema, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, so it meets the baseline of 4 for tools with no parameters, as it doesn't have to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'acomoのAPIスキーマ（components.schemas）の一覧を返す' (returns a list of acomo API schema components). It specifies the verb ('returns a list') and resource ('acomo API schema components'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'describe_component' or 'list_apis', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools such as 'describe_component' (for detailed info on a single component) or 'list_apis' (for listing APIs), nor does it specify any prerequisites or exclusions. This leaves the agent without clear usage context.
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 updates
v1.0.0- First observed
api_schemas - First observed
call_api - First observed
describe_api - First observed
describe_component - First observed
generate_request_template - First observed
health - First observed
list_apis - First observed
list_components
TDQS
B3.3/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: list_apis and list_components provide overviews, describe_api and describe_component give detailed information, api_schemas extracts specific parts, generate_request_template creates templates, call_api executes calls, and health checks server status. The descriptions make it easy to differentiate between listing, describing, extracting, generating, calling, and checking operations.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_apis, describe_api, call_api). The verbs (list, describe, generate, call, health) are clear and appropriately paired with nouns (apis, components, request_template, api), creating a predictable and readable naming convention throughout the set.
Tool Count5/5
With 8 tools, this server is well-scoped for its purpose of interacting with an API documentation system (acomo). Each tool serves a specific function in the workflow (listing, describing, extracting, generating, calling, and health checking), and none appear redundant or unnecessary, making the count appropriate for the domain.
Completeness5/5
The tool set provides complete coverage for the domain of API documentation exploration and interaction: it allows listing APIs and components, describing them in detail, extracting schemas, generating request templates, calling APIs, and checking server health. There are no obvious gaps, as it supports the full lifecycle from discovery to execution.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
- OneOAuthai.withone
Search, document and execute authenticated API calls across 700+ apps via one MCP server
Query, browse, and automate OmegaAI workspaces from any MCP client. Streamable HTTP with OAuth 2.0.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides a standardized MCP interface for interacting with HTTP tools and services, enabling unified API access and management.MIT
- FlicenseAqualityDmaintenanceExposes two MCP tools (discover and execute) that enable agents to query an OpenAPI schema via natural language and execute matched API operations.2-
- FlicenseNot gradedqualityDmaintenanceDynamically creates MCP tools and resources from OpenAPI specifications, with a React admin panel for managing configurations, monitoring, and invoking resources.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/progress-all/acomo-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server