AgentPMT - Marketplace For Autonomous Agents
Server Details
AgentPMT is the AI agent marketplace that turns any MCP-compatible AI assistant into an autonomous employee. Connect once and your agents gain access to a growing ecosystem of tools, workflows, and skills spanning communication, data analytics, development, file management, search, and more. AgentPMT dynamically discovers and orchestrates tools from across the MCP ecosystem, so your agents can independently find the right tool for any task without manual configuration.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3/5 across 5 of 5 tools scored. Lowest: 2.4/5.
Each tool targets a distinct function: issue reporting, human requests, tool search/execution, workflow creation, and workflow skills. No overlapping purposes.
All tools share the 'AgentPMT-' prefix but the naming pattern varies slightly (e.g., 'Report-Tool-Issue' vs 'Workflow-Creator'). Still predictable and mostly consistent.
5 tools is well-scoped for a marketplace server, covering essential operations without being excessive or insufficient.
Covers key workflows: tool usage, workflow creation, human requests, and issue reporting. Minor gap: workflow deletion is not explicitly mentioned, but overall coverage is strong.
Available Tools
5 toolsAgentPMT-Report-Tool-IssueReport Tool IssueCInspect
Report an issue with a tool to the AgentPMT team.
| Name | Required | Description | Default |
|---|---|---|---|
| tool_name | Yes | ||
| error_message | Yes | ||
| recommended_improvements | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits, such as side effects (e.g., ticket creation), permission requirements, or response type. With no annotations, the description fails to provide essential behavioral context.
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 sentence, which is concise but sacrifices necessary detail. It is front-loaded but does not earn its place as it provides minimal value beyond the tool name.
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 lack of annotations, output schema, and parameter descriptions, the description is incomplete. It does not explain the outcome of reporting or how to correctly fill parameters, leaving the agent underinformed.
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 0% and the description adds no information about the parameters. The agent receives no guidance on what values to provide for 'tool_name', 'error_message', or 'recommended_improvements'.
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 'Report' and the resource 'issue with a tool'. It is specific enough to differentiate from siblings like 'AgentPMT-Send-Human-Request', though it could be more explicit about the type of issues (e.g., bugs vs. feature requests).
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 sibling tools are listed but not compared. There is no mention of prerequisites or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AgentPMT-Send-Human-RequestAgentPMT Send Human RequestAInspect
AgentPMT Send Human Request - Send a request to your human to enable a tool, workflow, or add funds to your budget.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Product/workflow ObjectId for access requests, or optional target identifier for check_response lookup | |
| action | No | Operation to perform: send (default) or check_response. Only use check_response when send returned approval_required=true. | send |
| request | No | Freeform request body to send to the user (required when action=send) | |
| request_id | No | Mobile approval request ObjectId to check when action=check_response. | |
| request_type | No | Request type: add_funds, enable_tool, enable_workflow, notification_only, other (required when action=send). Use notification_only to send a message that does not require approval; do not wait after sending. | |
| include_request | No | When action=check_response, include the full request record in the response. |
Tool Definition Quality
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. It only states the basic action but fails to explain the two-step flow (send then check_response) or that the tool creates a mobile approval request and requires human intervention. Critical behavioral traits are missing.
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 sentence that front-loads the purpose. It is concise but wastes a few words by repeating the tool name. Still, it is efficiently sized for quick understanding.
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?
Despite having 6 parameters and no output schema, the description is insufficient. It does not explain the overall workflow (send followed by check_response) or any return behavior. The tool's complexity (two actions) demands more context for proper use.
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 baseline is 3. The description does not add any additional meaning beyond what the input schema already provides for each parameter. It merely restates the tool's purpose.
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 action: sending a request to a human to enable a tool, workflow, or add funds. It uses a specific verb and resource, and distinguishes itself from sibling tools which deal with reporting issues, tool search, workflow creation, and workflow skills.
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 clear context for when to use the tool (when you need to send a request to a human for approvals or notifications). However, it does not explicitly state when not to use it or mention alternatives, but the context from sibling tools helps differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AgentPMT-Tool-Search-and-ExecutionAgentPMT Tool Search and ExecutionBInspect
AgentPMT Tool Search and Execution - Unified interface for discovering, searching, and using AgentPMT tools without MCP refresh. Access tools required for workflows and skills here.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (1-based). Used when listing tools. | |
| query | No | Search query for text and semantic matching. If provided, performs hybrid search. | |
| action | Yes | Operation to perform: get_tools (discover tools - list/search/workflow), get_schema (full tool schema by ID), request_credentials (email user to add credentials), call_tool (execute a tool), get_instructions (help) | |
| message | No | Custom message to include in credential request notification (for request_credentials action) | |
| tool_id | No | Tool/product ID (required for get_schema and use actions) | |
| page_size | No | Number of results per page (1-100) | |
| tool_name | No | Alternative: Tool name to search for (for use action, searches then executes first match) | |
| parameters | No | Parameters to pass to the tool when using 'use' action | |
| workflow_id | No | Workflow/skill chain ID. If provided, returns all tools from that workflow. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It mentions the tool performs multiple actions (discover, search, use) but does not disclose side effects, error handling, or specifics like tool execution 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 concise with two sentences. It front-loads the core idea but repeats the title. It is efficient but could be slightly more structured.
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?
Despite the schema providing parameter details, the description lacks context on return values, error handling, and how to effectively use the different actions. For a tool with 9 parameters and multiple actions, the high-level summary is insufficient.
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 coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema; it only reiterates the action enum conceptually without explaining parameter relationships.
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 is a 'unified interface for discovering, searching, and using AgentPMT tools' and mentions avoiding MCP refresh. This clearly indicates the tool's purpose and differentiates it from sibling tools like reporting issues or creating workflows.
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 gives context by saying 'without MCP refresh' and 'Access tools required for workflows and skills here', implying when to use it. However, it does not explicitly state when not to use it or provide direct comparisons to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AgentPMT-Workflow-CreatorAgentPMT Workflow CreatorBInspect
AgentPMT Workflow Creator - Build and manage multi-step AI agent workflows (skill chains) that orchestrate tools, prompts, loops, and human notifications into reusable DAG pipelines. Supports creating, updating, publishing, remixing, searching, and adding showcase examples to workflows. Access a catalog of 170+ tools to chain together. Call get_instructions before starting.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Workflow skill name | |
| skip | No | Number of results to skip for pagination | |
| edges | No | Workflow graph edges - array with {id, from, to, condition, sourceHandle?, targetHandle?} | |
| limit | No | Maximum results to return (1-200) | |
| nodes | No | Workflow graph nodes - array of SkillChainNode objects | |
| query | No | Search query over name/description (case-insensitive) | |
| action | Yes | The action to perform | |
| sort_by | No | Sort order for fetch_tools browse (no search query). 'recently_updated' or 'name'. | recently_updated |
| skill_id | No | Skill chain ObjectId or slug (required for update, publish, remix, delete; optional for fetch) | |
| publisher | No | Filter by publisher username (case-insensitive substring match, for search_public) | |
| categories | No | Comma-separated category names to filter by (for search_public) | |
| chat_model | No | Override the workflow's chat model identifier. Must reference chat_model_config.available_models; null or blank clears the override on update. | |
| visibility | No | Visibility: private or public | |
| description | No | Workflow skill description | |
| tool_search | No | Search query for tools in fetch_tools action | |
| version_bump | No | Version bump type for publish: major, minor, patch, or auto | |
| industry_tags | No | List of industry tag names to associate with this workflow | |
| mcp_server_name | No | MCP server name (default: agentpmt) | |
| validation_mode | No | Validation mode for validate action. Defaults to agent_write. | agent_write |
| showcase_example | No | Single showcase example to add (for add_showcase_example action) | |
| time_saved_minutes | No | Estimated minutes saved (>= 0) | |
| context_document_id | Yes | Agent Context document ObjectId for attach_context/detach_context. | |
| showcase_example_id | No | Showcase example id to remove (for remove_showcase_example action) | |
| context_document_ids | No | Agent Context document ObjectIds to attach to the workflow (max enforced by the agent_context domain). Replaces the existing set when provided. | |
| industry_tags_filter | No | Comma-separated industry tag names to filter by (for search_public) | |
| default_export_target | No | Default export target: mcp or rest | |
| exclude_private_tools | No | If true, omit private tools from fetch_tools results | |
| remixed_from_skill_id | No | Source skill ID when creating a remix | |
| include_published_only | No | For fetch_existing: only return skills that have been published | |
| remixed_from_skill_name | No | Source skill name when creating a remix |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full burden. It lacks details on side effects of actions (e.g., update overwrites, delete permanence), prerequisites beyond get_instructions, or rate limits. The description is insufficient for safe invocation.
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 paragraph that efficiently conveys purpose and key details. It is front-loaded with the core function and includes actionable guidance (call get_instructions). While slightly dense, it earns its sentences.
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 30 parameters, nested objects, and no output schema, the description provides necessary context (actions, catalog, prerequisite) but omits return value details and handling of complex structures. Adequate but not comprehensive.
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 baseline is 3. The tool description does not add significant meaning beyond the schema; it lists actions but provides no additional parameter guidance. Thus, it meets the baseline without exceeding.
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 function: 'Build and manage multi-step AI agent workflows (skill chains).' It lists specific actions and mentions a catalog of 170+ tools, distinguishing it from siblings like AgentPMT-Tool-Search-and-Execution which focuses on individual tool execution.
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 advises to 'Call get_instructions before starting,' providing a usage hint. However, it does not explicitly compare to alternatives or state when not to use this tool versus sibling tools like AgentPMT-Workflow-Skills, leaving ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AgentPMT-Workflow-SkillsAgentPMT Workflow SkillsCInspect
AgentPMT Workflow Skills - Fetch, Search, and Use Agent Workflows and Skills. Use to retrieve, initiate, and complete workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Number of results to skip for pagination | |
| limit | No | Maximum results to return (1-200) | |
| query | No | Optional substring search over name/description (case-insensitive) | |
| action | Yes | Operation to perform: search, browse_industry, get_workflow_skill, start_workflow, end_workflow, get_active_workflow, get_instructions | |
| rating | No | Workflow rating from 1-5 stars (required for end_workflow) | |
| comment | No | Comment about the workflow experience (required for end_workflow) | |
| include | No | Comma-separated entity types to include for browse_industry: workflows, content, categories. Defaults to all. | |
| industry | No | Industry name or slug (required for browse_industry). Returns linked workflows, content, and categories. | |
| skill_id | No | Skill chain ObjectId or slug (required for get_workflow_skill, start_workflow, end_workflow) | |
| publisher | No | Filter by publisher username (case-insensitive substring match) | |
| categories | No | Comma-separated category names to filter by | |
| industry_tags | No | Comma-separated industry tag names to filter by | |
| suggested_improvements | No | Suggested improvements or changes to the workflow (optional) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It mentions 'initiate and complete workflows' implying state changes, but provides no details about permissions, side effects, or whether operations are reversible. This is insufficient for a mutation-heavy 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 a single short sentence with no wasted words. However, it is arguably too concise—key information is omitted. Conciseness is achieved at the expense of completeness, resulting in a mediocre score.
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 complexity (13 parameters, no output schema) and the presence of sibling tools, the description is too sparse. It does not explain return values, pagination behavior, or how actions interact. An agent would lack critical context to use this tool effectively.
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 baseline is 3. The description adds no additional meaning beyond the schema; it does not explain parameter relationships, required combinations, or usage patterns. The schema itself is clear, so the description does not harm but offers no extra value.
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 general purpose: fetching, searching, and using workflows/skills. However, it is vague and does not distinguish this tool from siblings like AgentPMT-Workflow-Creator or AgentPMT-Tool-Search-and-Execution. No specific resource or scope is given.
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or typical contexts. The agent receives no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!