Automated publishing workflow for deploying the MCP server package to PyPI when releases are created
Package distribution platform for publishing and installing the MCP server package
Database management capabilities including creating tables and managing database structures through the advanced server's tools
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., "@MCP Agents greet me with my name John"
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.
A simple Model Context Protocol (MCP) server built with FastMCP that demonstrates basic tool implementation.
greet: Greet a user by name
Related MCP server: penr-oz MCP Server
This project uses uv for package management and just for task running. Make sure you have both installed:
# Install uv if you don't have it
curl -LsSf https://astral.sh/uv/install.sh | sh
# Install just if you don't have it
# On macOS with Homebrew:
brew install just
# Or with cargo:
cargo install justThen build the project:
just buildTo start the MCP agents server:
just runYou can use this server with any MCP-compatible client. The configuration depends on how you want to run the server:
For development or when running from a local clone:
{
"mcpServers": {
"mcp-agents": {
"command": "uv",
"args": ["run", "mcp-agents"],
"cwd": "/Users/means/repository/mcp-agents",
"env": {}
}
}
}Once published to PyPI, users can use this simpler configuration:
{
"mcpServers": {
"mcp-agents": {
"command": "uvx",
"args": ["amajakai14_mcp-agents"]
}
}
}Alternative with pipx:
{
"mcpServers": {
"mcp-agents": {
"command": "pipx",
"args": ["run", "amajakai14_mcp-agents"]
}
}
}To pin to a specific version:
{
"mcpServers": {
"mcp-agents": {
"command": "uvx",
"args": ["amajakai14_mcp-agents==0.1.0"]
}
}
}Add any of the above configurations to your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
Run the test script to verify the tools work correctly:
just testGreets a user by name.
Parameters:
name (string): The name of the person to greet
Returns: A friendly greeting message.
Example:
{
"name": "greet",
"arguments": {
"name": "Alice"
}
}Response:
"Hello, Alice!"just build - Install dependencies and sync the project
just run - Start the MCP agents server
just test - Run the test script
just format - Format code with black and isort
just typecheck - Run type checking with mypy
just dev - Install development dependencies
just dist - Build distribution packages
just clean - Clean build artifacts
just publish - Publish to PyPI (used in CI)
mcp-agents/
├── src/
│ └── agents/
│ └── __init__.py # Main MCP server implementation
├── pyproject.toml # Project configuration and dependencies
├── justfile # Task runner configuration
├── mcp_config.json # MCP client configuration example
├── test_tools.py # Simple test script
└── README.md # This fileTo add new tools using FastMCP:
Add a new function with the @mcp.tool() decorator:
@mcp.tool("tool_name", description="Description of what the tool does")
def tool_name(param1: type, param2: type) -> return_type:
# Tool implementation
return resultUpdate the README with documentation for the new tool
just testMIT License
Get information about the Development Agent
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 'gets information', implying a read-only operation, but doesn't specify if it's safe, what data is returned, any rate limits, or authentication needs. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
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 a single, clear sentence: 'Get information about the Development Agent'. It is front-loaded with the core action and resource, with no wasted words or extraneous details. This makes it highly efficient and easy to parse at a glance.
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?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, it lacks details on what information is retrieved, how it differs from sibling tools, or any behavioral context. With no annotations and a generic purpose, it could be more complete to aid in tool selection and usage.
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?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, as there are none to explain. It appropriately avoids unnecessary parameter information, earning a baseline score of 4 for not introducing confusion or redundancy.
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 'Get information about the Development Agent' clearly states the action (get) and target resource (Development Agent), providing basic purpose. However, it doesn't differentiate from sibling tools like 'get_po_agent' or 'get_qa_agent' beyond the agent type, nor does it specify what kind of information is retrieved. This makes it somewhat vague compared to more specific alternatives.
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 such as 'list_all_agents'. It doesn't indicate if this is for detailed info on a single agent, if it requires specific permissions, or any contextual prerequisites. Without such guidance, users must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the Product Owner Agent
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 but only states what the tool does without details on traits like read-only status, error handling, or performance. It doesn't add context beyond the basic purpose, leaving gaps in understanding how the tool behaves in practice.
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 a single, clear sentence that efficiently conveys the tool's purpose with zero waste. It's appropriately sized for a no-parameter tool and front-loaded with essential information, making it easy to parse and understand quickly.
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?
Given the tool's simplicity (0 parameters, output schema provided), the description is adequate but minimal. It covers the basic purpose but lacks details on usage context or behavioral traits, which could be helpful despite the structured data. For a tool with no parameters and an output schema, this is a minimum viable description.
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?
The tool has 0 parameters, and the input schema has 100% description coverage, so there's no need for parameter details in the description. The baseline for this scenario is 4, as the description appropriately avoids redundant information and focuses on the tool's purpose without unnecessary complexity.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('information about the Product Owner Agent'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like get_dev_agent or get_qa_agent, which have similar naming patterns but target different agents.
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 like list_all_agents or other agent-specific getters. It lacks context on prerequisites, such as whether the agent must exist or be accessible, and doesn't mention any exclusions or specific scenarios for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the Quality Assurance Agent
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 the purpose without detailing traits like whether it's a read-only operation, authentication requirements, rate limits, or what the output includes. This is inadequate for a tool with zero annotation coverage.
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 a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
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?
Given the tool's simplicity (0 parameters, no annotations, but with an output schema), the description is minimally adequate. It states the purpose but lacks details on behavioral traits or output format, which the output schema might cover, leaving some gaps in completeness.
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?
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 details, and it doesn't contradict the schema, earning a baseline score above 3 due to the absence of parameters.
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's purpose ('Get information about the Quality Assurance Agent'), which is clear but vague. It uses a generic verb ('Get') without specifying what type of information is retrieved (e.g., configuration, status, details), and it doesn't differentiate from sibling tools like 'get_dev_agent' or 'list_all_agents' beyond the agent type.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context for usage, or comparisons to sibling tools such as 'get_dev_agent' or 'list_all_agents', leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available agents with their basic information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it lists agents with basic information. It doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, pagination, or what 'basic information' entails. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose without any wasted words. It is front-loaded and appropriately sized for a simple list operation, earning a top score for conciseness.
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?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, it lacks details on behavioral aspects (e.g., safety, performance) and doesn't leverage the output schema to clarify return values. For a list tool with no annotations, more context on behavior would improve completeness.
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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate. A baseline of 4 is applied since no parameters exist, and the description doesn't introduce unnecessary complexity.
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 clearly states the verb ('List') and resource ('all available agents'), specifying what information is returned ('basic information'). It distinguishes from siblings by listing 'all' agents rather than retrieving specific ones like 'dev', 'po', or 'qa' agents. However, it doesn't explicitly contrast with sibling tools, keeping it at 4 instead of 5.
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 like the sibling tools (get_dev_agent, get_po_agent, get_qa_agent). It doesn't indicate if this is for overview purposes, when specific agent retrieval is needed, or any prerequisites. This lack of comparative context results in a low score.
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. Dates show when Glama detected each change.
get_dev_agentget_po_agentget_qa_agentlist_all_agentsEach tool has a clearly distinct purpose: three tools retrieve information about specific agents (Development, Product Owner, Quality Assurance), while the fourth lists all agents. There is no overlap or ambiguity between these functions.
All tool names follow a consistent verb_noun pattern: 'get_dev_agent', 'get_po_agent', 'get_qa_agent', and 'list_all_agents'. The verbs 'get' and 'list' are appropriately used and maintain a predictable naming convention throughout.
With 4 tools, the count is reasonable for managing agent information, though it might feel slightly thin if more operations (e.g., create, update, delete agents) were expected. However, for a read-only information retrieval server, it is well-scoped.
The tool surface covers read operations (get and list) for agents, which is appropriate for an information retrieval purpose. However, there are notable gaps if the domain implies management capabilities, such as creating, updating, or deleting agents, which are missing.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI agent profiles and smart notes. 60+ coding prompt packs with expert personas.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for building and testing AI agents with multi-model experimentation and insights.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/amajakai14/mcp-agents'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
