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.

Ownership verified

Status: Healthy
Uptime: 53.7% over 38 days
OAuth: Works in Glama
Last Tested: 2026-09-24 20:39
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

B3.2/5.0

Scored 2026-09-11 07:55 across 5 tools

Disambiguation3/5

AgentPMT-Tool-Search-and-Execution and AgentPMT-Workflow-Skills overlap significantly, both handling retrieval and use of tools/workflows/skills. AgentPMT-Workflow-Creator is distinct for building workflows, and the other two tools (Issue, Human-Request) are clear, but the two search/execution tools could easily be confused.

Naming Consistency4/5

Most names follow a consistent AgentPMT-Prefix-Verb-Noun pattern (Report-Tool-Issue, Send-Human-Request, Workflow-Creator, Workflow-Skills), with minor variation in the long compound name Tool-Search-and-Execution. Mostly predictable and readable.

Tool Count5/5

Five tools is a well-scoped set for a marketplace agent's core needs: reporting, human communication, tool search/execution, workflow creation, and workflow skills. No obvious redundancy in count.

Completeness4/5

The surface covers discovery, execution, workflow building, human approval, and issue reporting, which is strong lifecycle coverage. However, there is no explicit tool for managing budgets or credentials beyond the human-request path, which may be a minor gap.

Available Tools

5 tools

AgentPMT-Report-Tool-IssueReport Tool IssueCInspect

Report an issue with a tool to the AgentPMT team.

ParametersJSON Schema

Name	Required	Description	Default
`tool_name`	Yes
`error_message`	Yes
`recommended_improvements`	No

TDQS

C2.4/5.0

Behavior2/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters1/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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 or notification to the human who owns your budget, then check their decision. Every send is delivered to the human by email, by push notification in the AgentPMT mobile app, and as a notice in the Messages tab of the AgentPMT dashboard; they approve or deny from any of the three. Use action=send with request_type enable_tool or credential_setup (id = product ObjectId, required), enable_workflow (id = workflow ObjectId, required), add_funds, other, or notification_only, plus a plain-language request (max 5000 characters). Approving enable_tool or enable_workflow adds the target to the current budget automatically; approving add_funds completes a credit purchase; approving credential_setup stores the connection credentials. send returns mobile_request_id and approval_required. When approval_required is true, poll with action=check_response and request_id until status is approved, denied, or expired, then read decision_notes and action_result before continuing. notification_only never requires approval and must not be polled. Free, no credentials required, always available.

ParametersJSON Schema

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.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations to fall back on, the description discloses key behaviors: delivery channels, approval side effects (budget addition, credit purchase, credential storage), return fields, polling statuses, and the fact that notification_only never requires approval. It also states that the tool is free and requires no credentials. This is substantial transparency beyond the schema.

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 a dense single paragraph with no filler and is front-loaded with the core purpose. It could be slightly easier to scan with bullets or clearer separation between the send flow and check_response flow, but every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema and no annotations, the description provides a complete operational picture: return values, poll loop, statuses, approval consequences, and credential/availability context. An agent has enough information to invoke the tool correctly and handle the async approval flow without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds critical parameter meaning beyond the schema: id is required for enable_tool/credential_setup and expects a product ObjectId, enable_workflow expects a workflow ObjectId, request has a 5000-character limit, and request_type values control behavior. Even though the schema has 100% coverage of parameter names, the description materially enriches how they should be populated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/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: send a request or notification to the human who owns the budget and then check their decision. It names the resource, the action, and the two operation modes (send/check_response), making it easy to distinguish from sibling tools like issue reporting or workflow creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit procedural guidance: use action=send with specific request types, poll with action=check_response only when approval_required is true, and never poll notification_only. It does not explicitly contrast with sibling tools, but within this tool's own workflow it provides clear when-to-use and when-not-to-use instructions.

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.

ParametersJSON Schema

Name	Required	Description
`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.

TDQS

B3.1/5.0

Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema

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.
`version_id`	No	Workflow version ObjectId for get_version and restore_version.
`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)
`checkpoint_reason`	No	Autosave checkpoint reason.
`time_saved_minutes`	No	Estimated minutes saved (>= 0)
`context_document_id`	No	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
`expected_draft_revision`	No	Required optimistic concurrency token for update, publish, delete, attach/detach, showcase, and restore actions.
`remixed_from_skill_name`	No	Source skill name when creating a remix

TDQS

B3.2/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 disclosure burden. Yet it is essentially a feature list—it does not disclose mutation side effects (delete, publish, restore are all destructive), permission/auth requirements, reversibility, or response shape. The only behavioral disclosure is the get_instructions prerequisite. For a tool that can delete and publish workflows, this is a meaningful gap.

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?

Three sentences with the core purpose front-loaded, followed by a compact capability list and a crucial usage directive. No filler or redundancy. It could trim the enumerated actions slightly, but for a tool with 20 actions and 33 params it remains appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a highly complex tool (20 actions, 33 params, nested objects, no output schema, no annotations), the description gives a solid high-level overview but lacks action-level routing—an agent is left guessing which of the 20 actions fits a given request. The 'call get_instructions' directive partially compensates by deferring detail, but the description itself does not make the tool safely callable without that extra step.

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 33 parameters with detailed descriptions. The description adds contextual framing (DAG, skill chains, tool catalog) that helps interpret complex params like nodes/edges, but it doesn't explain parameter interplay or action-specific requirements beyond what the schema already provides. Baseline 3 is appropriate.

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 states a clear purpose: building/managing multi-step AI agent workflows (skill chains) as DAG pipelines. It names the resource (workflows), the actions (create, update, publish, remix, search, showcase), and differentiates from siblings by framing itself as the workflow builder/manager. It doesn't explicitly contrast with AgentPMT-Workflow-Skills, leaving some sibling differentiation to inference, so it falls just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives one actionable directive: 'Call get_instructions before starting,' which is a useful prerequisite hint for a complex 20-action tool. However, it provides no when-to-use vs when-not-to-use guidance and never names alternatives among the siblings (e.g., when to route to AgentPMT-Workflow-Skills vs this creator). Usage context is implied but not explicit.

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.

ParametersJSON Schema

Name	Required	Description
`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)

TDQS

C2.5/5.0

Behavior2/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 10, 2026
- ChangedAgentPMT-Send-Human-Request3 fields changed
  - addedInput schema / properties / id / default
```
Added value: +null
```
  - addedInput schema / properties / request / default
```
Added value: +null
```
  - addedInput schema / properties / request_type / default
```
Added value: +null
```

1 tool updateJul 27, 2026

ChangedAgentPMT-Workflow-Creator4 fields changed

changedInput schema / properties / action / enum

Previous value: -[
-  "add_showcase_example",
-  "attach_context",
-  "create_new",
-  "delete",
-  "detach_context",
-  "fetch_existing",
-  "fetch_industry_tags",
-  "fetch_tools",
-  "get_instructions",
-  "publish",
-  "remix",
-  "remove_showcase_example",
-  "search_public",
-  "update_existing",
-  "validate"
-]New value: +[
+  "add_showcase_example",
+  "attach_context",
+  "checkpoint",
+  "create_new",
+  "delete",
+  "detach_context",
+  "fetch_existing",
+  "fetch_industry_tags",
+  "fetch_tools",
+  "get_instructions",
+  "get_version",
+  "list_versions",
+  "publish",
+  "remix",
+  "remove_showcase_example",
+  "restore_published",
+  "restore_version",
+  "search_public",
+  "update_existing",
+  "validate"
+]

addedInput schema / properties / checkpoint_reason

Added value: +{
+  "default": null,
+  "description": "Autosave checkpoint reason.",
+  "enum": [
+    "idle",
+    "window_blur",
+    "visibility_hidden"
+  ],
+  "type": "string"
+}

addedInput schema / properties / expected_draft_revision

Added value: +{
+  "default": null,
+  "description": "Required optimistic concurrency token for update, publish, delete, attach/detach, showcase, and restore actions.",
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / version_id

Added value: +{
+  "default": null,
+  "description": "Workflow version ObjectId for get_version and restore_version.",
+  "type": "string"
+}

1 tool updateJul 10, 2026
- ChangedAgentPMT-Workflow-Creator1 field changed
  - changedInput schema / required
```
Previous value: -[
-  "action",
-  "context_document_id"
-]New value: +[
+  "action"
+]
```
1 tool updateJul 8, 2026
- ChangedAgentPMT-Workflow-Creator1 field changed
  - changedInput schema / required
```
Previous value: -[
-  "action"
-]New value: +[
+  "action",
+  "context_document_id"
+]
```
1 tool updateJul 8, 2026
- ChangedAgentPMT-Workflow-Creator1 field changed
  - changedInput schema / required
```
Previous value: -[
-  "action",
-  "context_document_id"
-]New value: +[
+  "action"
+]
```

Publisher details

Operator: AgentPMT · Publisher source
Operator website: https://www.agentpmt.com · Publisher source
Vendor relationship: First-party
Documentation: https://www.agentpmt.com/dynamic-mcp · Publisher source
Trust center: https://www.agentpmt.com/terms · Publisher source
Restrictions: Free tier with additional paid credits available - https://www.agentpmt.com/pricing · Publisher source

Related MCP Connectors

CraloOAuth
ai.cralo
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Agent Orchestration Developer Tools
1
AxiomOAuth
com.axiomide
The marketplace where agents don't just use tools — they build, publish, and compose new ones.
Agent Orchestration Autonomous Agents Developer Tools
1
SkilderOAuth
ai.skilder
One place to build, share, and govern the skills and tools your AI agents use at work.
Developer Tools CI/CD & DevOps
1
skills-hub A
io.github.tinh2
Search & install 6,500+ AI agent skills from skills-hub.ai inside any MCP tool.
Autonomous Agents AI & Machine Learning Search
42

Related MCP Servers

MCP Hub
Agent Orchestration Autonomous Agents Developer Tools
cyber-lazer-mermicorn
A
license
Not graded
quality
B
maintenance
A universal MCP hub that connects any AI agent to any tool, enabling agent interoperability with 50+ pre-built tools, custom tool creation, and tool discovery.
Updated 14 days ago (2026-09-10 22:39 UTC)
565 npm
MIT
Cralo
Agent Orchestration App Automation
amrnth
F
license
Not graded
quality
C
maintenance
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Updated 25 days ago (2026-08-31 05:21 UTC)
-
agent-discover
Agent Orchestration Developer Tools
keshrath
A
license
Not graded
quality
C
maintenance
MCP server registry and marketplace that enables dynamic discovery, installation, and activation of tools at runtime, allowing AI agents to use new tools without restarting.
Updated 5 months ago (2026-04-19 17:51 UTC)
57 npm
7
MIT
aiskillstore
Autonomous Agents Agent Orchestration
garasegae
A
license
A
quality
F
maintenance
Agent-first skill marketplace MCP server. AI agents discover, install, and share skills across 7 platforms via MCP protocol. 15 tools including skill search, download, upload, and agent discovery.
Updated 4 months ago (2026-05-14 04:39 UTC)
18
4
MIT

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?