Find MCP - Agentage MCP Directory

Get one MCP server

mcp_get

Read-only

Fetch the complete record for ONE MCP server in the agentage directory by its canonical slug: full description, categories, the packages and remote endpoints it ships, the tools it exposes, a ready-to-run install command, and a README excerpt. Use this after mcp_search to get the depth a result card omits - pass a slug exactly as returned by mcp_search. Slugs are canonical and registry-derived ("io-github-github-github-mcp-server"), NOT the plain product name ("github"); if you pass a plain name anyway it is resolved by search as a fallback - a single confident match returns that server (with resolved_from set), anything else returns an error naming the candidate slugs to retry with. No slug yet? call mcp_search first. Read-only.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	Yes	The canonical slug of one server, taken verbatim from a mcp_search result. Catalog slugs are registry-derived and rarely match the plain product name (e.g. "io-github-github-github-mcp-server", not "github"), so prefer a slug from mcp_search. A plain name is accepted as a best-effort fallback: it resolves only when exactly one server matches, otherwise the error lists candidate slugs.

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes
`slug`	Yes
`title`	Yes
`tools`	Yes	The MCP tools this server exposes, from its live tools/list
`install`	No	The recommended way to run this server, derived from its first package/remote
`license`	No
`remotes`	Yes
`category`	Yes
`language`	No
`packages`	Yes
`description`	Yes
`details_url`	Yes	Human detail page for this server - open it for more information
`is_official`	Yes
`resolved_from`	No	Present only when the requested slug was not canonical and was resolved by name; this is what you asked for - use `slug` from now on
`readme_excerpt`	No	First ~2000 chars of the README; open details_url for the full document
`transport_types`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: slug canonicalization rules, fallback resolution with `resolved_from`, and error listing candidate slugs. This goes well beyond the structured 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 moderately long but every sentence earns its place: purpose, contents, usage sequence, slug format, fallback behavior, and read-only note. It is front-loaded and well organized with no filler.

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 only one parameter, an output schema present, and annotations covering safety, the description covers all needed context: when to use, how to source the slug, fallback behavior, and read-only nature. No significant gaps remain.

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% and the slug parameter's schema description already includes verbatim-from-search guidance, canonical format, and fallback behavior. The tool description adds minimal new meaning beyond this, so baseline 3 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 fetches one MCP server's complete record by canonical slug, enumerating the contents (description, categories, packages, endpoints, tools, install command, README). It distinguishes itself from mcp_search by noting it provides depth beyond result cards.

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

Usage Guidelines5/5

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

Explicitly instructs to use this after mcp_search and to call mcp_search first if no slug is available. It also explains the fallback resolution for plain names and error behavior, giving unambiguous when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Find MCP - Agentage MCP Directory tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: mcp_categories lists filter values, mcp_search finds servers, and mcp_get retrieves full details for a single server. There is no overlap or ambiguity in their responsibilities.

Naming Consistency4/5

All tools use the mcp_ prefix, but the pattern is slightly mixed: mcp_search and mcp_get are verb-first, while mcp_categories is a noun. The convention is still predictable and readable, so this is a minor deviation.

Tool Count5/5

Three tools is exactly right for a directory service: one to discover filter options, one to search, and one to fetch details. No tool is redundant or missing.

Completeness5/5

The tools cover the complete read-only workflow for the domain: browse categories, search with filters, and inspect a server's full record. There are no dead ends or obvious gaps; the dependency between mcp_categories and mcp_search is well-documented.

Resources

Need Help?