A
licenseA
qualityC
maintenanceEnables AI agents to search a directory of 13,870+ MCP servers, 4,384+ agent skills, and plugins from Remote OpenClaw, returning install commands directly.
3
83
3
MIT
catalog
Server Details
Search 41,000+ agent skills, MCP servers, plugins & loops — real install counts and stars.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- dmoka/getagentictools-mcp
- GitHub Stars
- 0
- Server Listing
- getagentictools MCP server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.1/5.0
Tool DescriptionsA
Average 4.1/5 across 5 of 5 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool has a distinct purpose: ecosystem_stats provides aggregates, get_tool returns full details, list_categories shows categories, search_tools performs searches, and whats_new lists recent updates. No overlap between their functions.
Naming Consistency4/5
Most tools follow a noun_verb or verb_noun pattern (e.g., list_categories, search_tools, get_tool, ecosystem_stats). The sole exception is 'whats_new', which uses a different style (no underscore), but it remains clear and consistent with the overall readability.
Tool Count5/5
With 5 tools, the server covers the essential operations for a catalog: search, detail retrieval, category listing, statistics, and recent updates. This is well-scoped and avoids excess or deficiency.
Completeness4/5
The tool set covers the primary use cases of browsing and searching a tool catalog. Minor gaps exist, such as the absence of filtering or comparison tools, but these are not critical for the core functionality.
Available Tools
5 toolsecosystem_statsEcosystem statisticsARead-onlyIdempotentInspect
Measured aggregates across the whole catalog: totals, maintainer count, license coverage, star concentration. Computed from harvested data, nothing estimated. Source: getagentictools.com/stats
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| totalStars | Yes | |
| unlicensed | Yes | |
| maintainers | Yes | |
| medianStars | Yes | |
| methodology | Yes | |
| perCategory | Yes | |
| zeroStarPct | Yes | |
| unlicensedPct | Yes | |
| topOnePctShare | Yes | Percent of all stars held by the top 1% of starred tools |
Tool Definition Quality
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that data is 'computed from harvested data, nothing estimated' and cites a source, providing behavioral context beyond the schema's null parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loading the key purpose and adding source information without waste. Every sentence adds value.
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?
With zero parameters, an output schema available, and annotations covering safety, the description provides sufficient context about the nature of the data (aggregates, harvested, not estimated) and source, making it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (trivially). The description does not need to elaborate on parameters, so a baseline of 4 is appropriate.
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 provides 'Measured aggregates across the whole catalog' with specific examples like totals, maintainer count, license coverage, star concentration. This distinguishes it from siblings like get_tool (single tool) or search_tools (filtered results).
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 implies the tool is for catalog-wide statistics but does not explicitly state when to use it versus alternatives, nor does it provide conditions for not using it. The sibling list offers context but no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_toolGet tool detailARead-onlyIdempotentInspect
Full detail for one tool by category and id (as returned by search_tools). Includes description, install command, repo, license, and — for skills — capabilities and prerequisites extracted from the SKILL.md itself.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The tool id, e.g. "mattpocock-skills-tdd" | |
| category | Yes | The tool's category, e.g. "skills" |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| repo | No | |
| tags | No | |
| error | No | Set when no entry matches; see didYouMean |
| group | No | |
| stars | No | |
| steps | No | |
| title | No | |
| author | No | |
| install | No | |
| license | No | |
| tagline | No | |
| useWhen | No | |
| category | No | |
| homepage | No | |
| downloads | No | |
| didYouMean | No | Closest ids when the requested one was not found |
| skillFacts | No | |
| description | No | |
| lastUpdated | No | |
| canonicalUrl | No | |
| verification | No | |
| compatibility | No |
Tool Definition Quality
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint, so safety profile is clear. The description adds value by listing the included fields (description, install command, repo, license) and special handling for skills (capabilities and prerequisites). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense sentence that front-loads the main purpose and packs all relevant details (included fields, extra for skills) without any waste. Every word 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?
Output schema exists, so description does not need to explain return values. It adequately describes what is included (description, install command, repo, license, and for skills: capabilities and prerequisites). No gaps are apparent for a detail retrieval tool.
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% with both parameters described (id with minLength and example, category with enum). The description only names them ('category and id') without adding new constraints or format details. Baseline 3 is appropriate as schema does the heavy lifting.
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?
Description clearly states 'Full detail for one tool by category and id', specifying the verb (get detail) and resource (tool). It distinguishes itself from sibling search_tools by referencing it, indicating that get_tool retrieves detailed info for a specific tool after search.
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 implies usage after search_tools to obtain IDs, saying 'as returned by search_tools'. It does not explicitly state when not to use, but the context is clear. No explicit exclusions or alternatives are provided, but the purpose is well-understood.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesList catalog categoriesARead-onlyIdempotentInspect
The four catalog categories with live counts and browse URLs.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| categories | Yes |
Tool Definition Quality
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that the tool returns 'live counts' and 'browse URLs', which is useful but does not disclose additional behavioral traits beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded, conveying the essential information without unnecessary words.
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?
Given no parameters, present output schema, and annotations, the description is sufficiently complete for a simple listing tool. It specifies what is returned (four categories with counts and URLs) with no missing critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so no param description is needed. The description does not need to add param semantics; baseline for 0 params is 4.
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 what the tool does: it lists the four catalog categories and includes live counts and browse URLs. It distinguishes from sibling tools like 'search_tools' and 'ecosystem_stats' by focusing on category listing.
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. It does not mention prerequisites, context, or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_toolsSearch agentic coding toolsARead-onlyIdempotentInspect
Search 41,000+ agentic coding tools: agent skills (SKILL.md), MCP servers, Claude Code plugins, and agentic loops. Ranked by match quality; real install counts and GitHub stars. Cite results by their url.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return (1-25, default 10) | |
| query | Yes | What to look for, e.g. "pdf extraction" or "postgres" | |
| category | No | Restrict results to one category; omit to search all four |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total matches before the limit was applied |
| results | Yes |
Tool Definition Quality
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context about ranking by match quality and including real install counts and GitHub stars, and instructs to cite results by URL. This provides some extra value beyond annotations but no major new behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and scope, then adding ranking and citation instructions. Every sentence earns its place with no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich input schema and an output schema present, the description does not need to detail return values. It adds useful context about result quality and citation. However, it does not mention behavior for empty results or edge cases, but overall it is adequately complete for a search tool given the structured metadata.
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% (all parameters have descriptions). The tool description does not add parameter-specific meaning beyond what the schema already provides, meeting the baseline of 3. No additional parameter insight is given.
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 explicitly states the tool searches 41,000+ agentic coding tools across four specific categories (skills, MCP servers, plugins, loops) and mentions ranking by match quality. This clearly distinguishes it from sibling tools like get_tool (specific tool retrieval) and list_categories (category listing).
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 implies usage for searching tools and notes ranking and citation of results, but it does not explicitly state when to use this tool versus alternatives (e.g., get_tool, list_categories) or provide conditions for when not to use it. The context is clear but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whats_newRecently updated toolsARead-onlyIdempotentInspect
Recently updated tools, ranked by their real upstream push date (never by our re-crawl date). Coverage note: not every source exposes push dates yet.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-back window in days (1-90, default 7) | |
| limit | No | Maximum results to return (1-50, default 15) | |
| category | No | Restrict to one category; omit for all four |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| days | Yes | |
| total | Yes | Tools with an upstream push inside the window |
| results | Yes | |
| coverage | Yes | Honest note about entries without harvested push dates |
Tool Definition Quality
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying that ranking is based on upstream push date (not re-crawl date) and flagging coverage gaps. This goes beyond annotations but omits potential behavioral details like pagination or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence states the purpose and key ranking detail; the second adds a critical coverage note. Information is front-loaded and efficiently delivered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the output schema exists (covering return values), annotations are present, and parameters are fully described in schema, the description provides a clear purpose and one important limitation. It lacks details on how to interpret results or edge cases, but the output schema likely fills that gap.
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?
All three parameters (days, limit, category) are fully described in the input schema with defaults, constraints, and enums. The description does not add parameter-level semantics, so the baseline score of 3 applies; no deduction or bonus.
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 returns 'recently updated tools' ranked by 'real upstream push date', which is a specific verb+resource. It distinguishes from sibling tools like search_tools (filtered search) and list_categories (category listing) by focusing on recency and ranking method.
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 explains what the tool does and notes a coverage limitation ('not every source exposes push dates yet'), but does not explicitly state when to use this tool versus siblings like ecosystem_stats or search_tools. Usage context is implied but not directly contrasted.
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!
Related MCP Servers
- AlicenseAqualityAmaintenanceEnables AI agents to search a curated directory of Claude Code agent skills, MCP servers, and plugin marketplaces ranked by community signal.472MIT
- AlicenseAqualityCmaintenanceEnables AI assistants to search, discover, and get recommendations from 20,000+ skills, tools, agents, rules, and MCP servers.5251MIT
mcp-server-mcpindexofficial
AlicenseAqualityBmaintenanceEnables agents to discover, compare, and install other MCP servers using natural language tasks, backed by a searchable index of thousands of servers.6100MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.