Skip to main content
Glama
enesjakozh
dkmaker

mcp-function-app-tester

by dkmaker
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

MCP 함수 앱 테스터

라이센스: MIT

Cline을 통해 Azure Function App을 테스트할 수 있는 TypeScript 기반 MCP 서버입니다. 이 도구를 사용하면 개발 환경에서 직접 Function App 엔드포인트를 테스트하고 상호 작용할 수 있습니다.

설치

지엑스피1

Related MCP server: MySQL Server MCP Server

특징

  • 다양한 HTTP 메서드를 사용한 테스트 기능 앱 엔드포인트

  • GET, POST, PUT 및 DELETE 요청 지원

  • 자세한 응답 정보

  • 사용자 정의 헤더 지원

  • POST/PUT 메서드에 대한 요청 본문 처리

  • 인증 지원:

    • 기본 인증(사용자 이름/비밀번호)

    • 베어러 토큰 인증

    • API 키 인증(사용자 정의 헤더)

입증

서버는 환경 변수를 통해 구성할 수 있는 두 가지 인증 방법을 지원합니다.

기본 인증

두 환경 변수를 모두 설정하여 기본 인증을 활성화합니다.

AUTH_BASIC_USERNAME=your-username
AUTH_BASIC_PASSWORD=your-password

베어러 토큰

Bearer 토큰 인증을 활성화하려면 이 환경 변수를 설정하세요.

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 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

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.

  1. 1 tool updatev1.0.0
    • First observedtest_endpoint
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

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

Related MCP Connectors

Related MCP Servers

  • mcp-rest-api

    dkmaker
    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
    103 npm
    101
    MIT

  • Azure CLI MCP

    jdubois
    -
    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
    -

  • interactive-mcp

    mikeysrecipes
    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
    23 npm
    1
    MIT

Appeared in Searches