이는 Brightsy AI 에이전트에 연결되는 MCP(Model Context Protocol) 서버입니다.
지엑스피1
Related MCP server: AI Helper MCP Server
서버를 시작하려면:
npm start -- --agent-id=<your-agent-id> --api-key=<your-api-key>또는 위치적 인수를 사용하여:
npm start -- <your-agent-id> <your-api-key> [tool-name] [message]또한 상담원에게 보낼 초기 메시지를 제공할 수도 있습니다.
npm start -- --agent-id=<your-agent-id> --api-key=<your-api-key> --message="Hello, agent!"기본적으로 MCP 서버는 "brightsy"라는 이름의 도구를 등록합니다. --tool-name 매개변수를 사용하여 이 이름을 사용자 지정할 수 있습니다.
npm start -- --agent-id=<your-agent-id> --api-key=<your-api-key> --tool-name=<custom-tool-name>도구 이름을 세 번째 위치 인수로 설정할 수도 있습니다.
npm start -- <your-agent-id> <your-api-key> <custom-tool-name>또는 BRIGHTSY_TOOL_NAME 환경 변수를 사용합니다.
export BRIGHTSY_TOOL_NAME=custom-tool-name
npm start -- --agent-id=<your-agent-id> --api-key=<your-api-key>다음 환경 변수를 사용하여 서버를 구성할 수 있습니다.
BRIGHTSY_AGENT_ID : 사용할 에이전트 ID(명령줄 인수의 대안)
BRIGHTSY_API_KEY : 사용할 API 키(명령줄 인수의 대안)
BRIGHTSY_TOOL_NAME : 등록할 도구 이름(기본값: "brightsy")
agent_proxy 도구를 사용하면 Brightsy AI 에이전트로 요청을 프록시할 수 있습니다. 제공된 테스트 스크립트를 사용하여 이 도구를 테스트할 수 있습니다.
테스트를 실행하기 전에 다음 환경 변수를 설정하세요.
export AGENT_ID=your-agent-id
export API_KEY=your-api-key
# Optional: customize the tool name for testing
export TOOL_NAME=custom-tool-name또는 다음 값을 명령줄 인수로 전달할 수 있습니다.
# Using named arguments
npm run test:cli -- --agent-id=your-agent-id --api-key=your-api-key --tool-name=custom-tool-name
# Using positional arguments
npm run test:cli -- your-agent-id your-api-key custom-tool-name모든 테스트를 실행하려면:
npm test특정 테스트를 실행하려면:
# Test using the command line interface
npm run test:cli
# Test using the direct MCP protocol
npm run test:direct명령줄 테스트 ( test-agent-proxy.ts ): 테스트 메시지로 MCP 서버를 실행하여 agent_proxy 도구를 테스트합니다.
직접 MCP 프로토콜 테스트 ( test-direct.ts ): 올바르게 형식화된 MCP 요청을 서버에 직접 전송하여 agent_proxy 도구를 테스트합니다.
MCP 서버는 OpenAI 호환 AI 에이전트에 요청을 전달하고 응답을 반환하는 도구(기본적으로 "brightsy")를 등록합니다. 이 도구는 role 및 content 속성을 가진 메시지 객체의 배열인 messages 매개변수를 사용합니다.
MCP 클라이언트에서의 사용 예:
// Using the default tool name
const response = await client.callTool("brightsy", {
messages: [
{
role: "user",
content: "Hello, can you help me with a simple task?"
}
]
});
// Or using a custom tool name if configured
const response = await client.callTool("custom-tool-name", {
messages: [
{
role: "user",
content: "Hello, can you help me with a simple task?"
}
]
});응답에는 content 필드에 에이전트의 답변이 포함됩니다.
Proxy requests to an Brightsy AI agent
| Name | Required | Description | Default |
|---|---|---|---|
| messages | Yes | The messages to send to the agent |
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 'proxy requests' which implies some form of communication forwarding, but doesn't describe authentication requirements, rate limits, error handling, response format, or what the Brightsy AI agent actually does. This leaves significant behavioral gaps for a proxying tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, with zero wasted language. It's front-loaded with the core purpose and contains no unnecessary elaboration. This is an example of efficient communication that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a proxying tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the Brightsy AI agent is, what types of requests are proxied, what authentication is needed, or what format the responses take. The combination of vague purpose and missing behavioral context creates significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'messages' parameter with its structure. The description adds no additional parameter semantics beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'proxy requests to an Brightsy AI agent', which provides a basic verb+resource combination. However, it's vague about what 'proxy requests' specifically entails - whether it's for chat, API calls, or other interactions. Without sibling tools, differentiation isn't needed, but the purpose lacks specificity about the nature of the proxying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor any context about prerequisites or appropriate scenarios. With no sibling tools, the absence of explicit 'when-not-to-use' guidance is less critical, but there's still no usage context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0brightsyScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'brightsy' has a clear and distinct purpose as a proxy to the Brightsy AI agent.
A single tool inherently has perfect naming consistency, as there are no other tools to compare against. The name 'brightsy' is straightforward and matches the server's purpose.
A single tool is generally too few for most server purposes, as it offers minimal functionality and can limit agent capabilities. While it might suffice for a simple proxy, it feels thin and under-scoped for typical MCP server expectations.
The tool surface is incomplete for a general-purpose AI agent proxy, lacking operations like configuration, status checks, or specific request types. However, the single tool covers the basic proxy function, leaving notable gaps but not entirely failing.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Connect AI agents to Replynodes over the Model Context Protocol.
A Model Context Protocol server for Wix AI tools
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
