A
licenseA
qualityF
maintenanceA TypeScript-based MCP server that enables testing of REST APIs through Cline. This tool allows you to test and interact with any REST API endpoints directly from your development environment.
1
103 npm
101
MIT
mcp-function-app-tester
by dkmaker
MCP 関数アプリテスター
Cline を介して Azure Function App のテストを可能にする TypeScript ベースの MCP サーバーです。このツールを使用すると、開発環境から直接 Function App エンドポイントをテストし、操作することができます。
インストール
npm install dkmaker-mcp-function-app-testerRelated MCP server: MySQL Server MCP Server
特徴
さまざまな HTTP メソッドを使用して Function App エンドポイントをテストする
GET、POST、PUT、DELETEリクエストのサポート
詳細な回答情報
カスタムヘッダーのサポート
POST/PUTメソッドのリクエストボディの処理
認証サポート:
基本認証（ユーザー名/パスワード）
ベアラートークン認証
APIキー認証（カスタムヘッダー）
認証
サーバーは、環境変数を介して構成できる 2 つの認証方法をサポートしています。
基本認証
両方の環境変数を設定して、基本認証を有効にします。
AUTH_BASIC_USERNAME=your-username
AUTH_BASIC_PASSWORD=your-password無記名トークン
ベアラートークン認証を有効にするには、この環境変数を設定します。
AUTH_BEARER=your-tokenAPIキー
API キー認証を有効にするには、両方の環境変数を設定します。
AUTH_APIKEY_HEADER_NAME=X-API-Key # The header name to use (e.g., X-API-Key, api-key, etc.)
AUTH_APIKEY_VALUE=your-api-key # The actual API key value注: 認証の優先順位:
基本認証（ユーザー名とパスワードが設定されている場合）
ベアラートークン（トークンが設定されていて、Basic 認証が設定されていない場合）
API キー (ヘッダー名と値が設定されていて、他の認証が設定されていない場合)
使用法
インストールが完了すると、Cline 経由で Function App Tester を使用できるようになります。サーバーは、ベース URL ( http://localhost:7071/apiでエンドポイントをテストするためのツールを提供します。
使用例:
// Test a GET endpoint
{
"method": "GET",
"endpoint": "/users"
}
// Test a POST endpoint with body
{
"method": "POST",
"endpoint": "/users",
"body": {
"name": "John Doe",
"email": "john@example.com"
}
}
// Test with custom headers
{
"method": "GET",
"endpoint": "/secure/data",
"headers": {
"Authorization": "Bearer token123"
}
}発達
リポジトリをクローンします。
git clone https://github.com/dkmaker/mcp-function-app-tester.git
cd mcp-function-app-tester依存関係をインストールします:
npm installプロジェクトをビルドします。
npm run build自動リビルドを使用した開発の場合:
npm run watchライセンス
このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細についてはLICENSEファイルを参照してください。
Available Tools
1 tooltest_endpointC
Test a Function App endpoint and get detailed response information. The endpoint will be prepended to the base url which is: http://localhost:7071/api
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Optional request body for POST/PUT requests | |
| endpoint | Yes | Endpoint path (e.g. "/users"). Will be appended to base URL. | |
| headers | No | Optional request headers | |
| method | Yes | HTTP method to use |
TDQS
C2.9/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. It mentions testing an endpoint and getting 'detailed response information,' but lacks critical behavioral details such as error handling, timeout behavior, authentication requirements, rate limits, or what 'detailed' entails. This is insufficient for a tool that performs HTTP operations.
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 concise and front-loaded, consisting of two sentences that directly state the tool's purpose and base URL. There is no wasted text, though it could be slightly more informative without sacrificing brevity.
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 HTTP testing (4 parameters, no output schema, no annotations), the description is incomplete. It lacks details on response format, error cases, or behavioral traits, leaving significant gaps for an agent to understand how to use the tool 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?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value by noting the base URL context ('http://localhost:7071/api'), but does not provide additional semantics beyond what the schema already covers. This meets the baseline for high schema coverage.
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: 'Test a Function App endpoint and get detailed response information.' It specifies the verb ('test') and resource ('Function App endpoint'), and mentions the base URL context. However, with no sibling tools, it cannot differentiate from alternatives, 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, prerequisites, or constraints. It only states what the tool does without context for its application, 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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
test_endpoint
TDQS
B3/5.0
Scored across 1 tool
Disambiguation5/5
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool has a clear, distinct purpose that cannot be confused with any other tool in this set.
Naming Consistency5/5
The naming follows a consistent verb_noun pattern (test_endpoint). With only one tool, there is no inconsistency to evaluate, and the naming is clear and appropriate for its function.
Tool Count2/5
A single tool is too few for a server named 'mcp-function-app-tester', which suggests broader testing capabilities. This minimal set feels thin and incomplete for the implied scope of testing Function App endpoints comprehensively.
Completeness1/5
The tool surface is severely incomplete for testing Function App endpoints. It only provides a basic test endpoint function, lacking essential operations like listing endpoints, managing test configurations, validating responses, or handling different HTTP methods and authentication scenarios.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
A TypeScript MCP server for Home Assistant, enabling programmatic management of entities, automati…
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA TypeScript-based MCP server that facilitates SQL query execution and MySQL database connectivity using environment variables.125 npmMIT
- -licenseNot gradedqualityNot gradedmaintenanceAn MCP server that wraps the Azure CLI. As LLMs are very good at generating Azure CLI commands, this server allows your LLM to list resources, update/create/delete them, fix errors (by looking at the logs), fix security issues...81-
- AlicenseAqualityDmaintenanceA Node.js/TypeScript MCP server that facilitates interactive communication between LLMs and users, allowing AI assistants to request user input, display notifications, and manage command-line chat sessions.523 npm1MIT