Skip to main content
Glama
dkmaker

mcp-function-app-tester

by dkmaker

MCP 功能应用测试器

许可证:MIT

基于 TypeScript 的 MCP 服务器,支持通过 Cline 测试 Azure Function App。此工具允许您直接从开发环境测试 Function App 端点并与其交互。

安装

npm install dkmaker-mcp-function-app-tester

Related MCP server: MySQL Server MCP Server

特征

  • 使用不同的 HTTP 方法测试 Function App 端点

  • 支持 GET、POST、PUT 和 DELETE 请求

  • 详细响应信息

  • 自定义标题支持

  • POST/PUT 方法的请求主体处理

  • 身份验证支持:

    • 基本身份验证(用户名/密码)

    • Bearer Token 身份验证

    • API 密钥认证(自定义标头)

验证

服务器支持两种可以通过环境变量配置的身份验证方法:

基本身份验证

设置两个环境变量以启用基本身份验证:

AUTH_BASIC_USERNAME=your-username
AUTH_BASIC_PASSWORD=your-password

持有者令牌

设置此环境变量以启用 Bearer Token 身份验证:

AUTH_BEARER=your-token

API 密钥

设置两个环境变量以启用 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

注意:身份验证优先顺序:

  1. 基本身份验证(如果设置了用户名和密码)

  2. 持有者令牌(如果设置了令牌并且未配置基本身份验证)

  3. 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"
  }
}

发展

  1. 克隆存储库:

git clone https://github.com/dkmaker/mcp-function-app-tester.git
cd mcp-function-app-tester
  1. 安装依赖项:

npm install
  1. 构建项目:

npm run build

对于使用自动重建的开发:

npm run watch

执照

该项目根据 MIT 许可证获得许可 - 有关详细信息,请参阅LICENSE文件。

Available Tools

1 tool
test_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
NameRequiredDescriptionDefault
bodyNoOptional request body for POST/PUT requests
endpointYesEndpoint path (e.g. "/users"). Will be appended to base URL.
headersNoOptional request headers
methodYesHTTP 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. Dates show when Glama detected each change.

  1. 1 tool updatev1.0.0
    • First observedtest_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

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

Related MCP Servers

  • A
    license
    A
    quality
    F
    maintenance
    A 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
    71
    101
    MIT
  • -
    license
    Not graded
    quality
    Not graded
    maintenance
    An 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
    -
  • A
    license
    A
    quality
    D
    maintenance
    A 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.
    5
    36
    1
    MIT

Latest Blog Posts

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/dkmaker/mcp-function-app-tester'

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