Read-only MCP server over 50 book-based agent skills: routes a task to the right framework.
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.
Average 4.6/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: get_journey for journeys, get_skill for metadata, load_skill for actual instructions, recommend_skills for task routing, search_skills for keyword search. Even the two skill-related tools are well-differentiated by their descriptions (metadata vs. instructions).
All tool names follow a consistent verb_noun pattern in snake_case (get_journey, get_skill, load_skill, recommend_skills, search_skills). The verbs are descriptive (get, load, recommend, search) and the nouns clearly indicate the target resource. No mixing of conventions.
With 5 tools, the server is well-scoped for its purpose of accessing and recommending skills. Each tool earns its place: single retrieval, search, routing, and deep loading. This is within the ideal 3-15 range and feels neither sparse nor bloated.
The tool surface covers the full lifecycle for the domain: discovering skills (search), selecting the right ones (recommend), retrieving metadata (get_skill), loading full instructions (load_skill), and exploring guided journeys (get_journey). No obvious missing operations—this is a read-only access server, and all necessary access patterns are present.
get_journeyGet a guided journeyAOne guided journey as a phase plan: the ordered skills, the decision question each phase answers, the docs/ file it writes, and which phases are go/no-go gates. Pass slug for a known journey, or goal to have one picked.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | What you are trying to achieve, if you do not know which journey fits | |
| slug | No | Journey slug, e.g. "grow-website" | |
| context | Yes | Why are you calling this tool? One line on the user's actual task, in their words — not a restatement of the tool name. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| next | Yes | |
| slug | Yes | |
| notFor | Yes | |
| phases | Yes | |
| install | Yes | |
| tagline | Yes | |
| useWhen | Yes | |
| artifacts | Yes | |
| canonical | Yes | |
| definition | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description complements the readOnly and idempotent annotations by explaining what a journey contains and how parameters affect the selection. It does not contradict the annotations and adds useful context about the tool's behavior without needing to restate the obvious read-only nature.
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 succinct and well-structured, packing all necessary information into two sentences. It directly states what the tool returns and how to invoke it, with no redundant or confusing wording.
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?
The description fully explains the tool's output (a journey plan with its components) and the two usage modes, covering both parameters and the tool's behavior. Given the simple schema and no return schema, this is complete and self-contained.
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 schema already defines each parameter, but the description adds valuable meaning: it explains that 'slug' identifies a specific journey and 'goal' triggers an automatic selection. This clarifies the usage of both optional parameters beyond their basic type definitions, enriching the schema's coverage.
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 that this tool retrieves a guided journey, which is a phase plan with specific components (ordered skills, decision questions, docs file writes, go/no-go gates). It distinguishes from siblings like get_skill or search_skills by focusing on journeys, making its purpose unambiguous.
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?
It explicitly states when to use the tool: pass a slug for a known journey, or pass a goal to have one picked. This gives clear situational guidance, though it doesn't explicitly mention when not to use it in favor of alternatives, which is implicit from the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_skillGet skill metadataAMetadata for one skill or journey: its definition, when to use it, when not to, and related slugs. Deliberately cheap (~300 tokens) so you can check a candidate before committing context to it. Pass sections to widen, or sections:["all"] for the whole page. This does not return the skill instructions — load_skill does.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Skill or journey slug, e.g. "refactoring-ui" or "create-business" | |
| context | Yes | Why are you calling this tool? One line on the user's actual task, in their words — not a restatement of the tool name. | |
| sections | No | Which parts to return. Default: definition, use_when, not_for, related. "all" returns the full page. |
| Name | Required | Description |
|---|---|---|
| book | No | |
| faqs | No | |
| kind | Yes | |
| name | Yes | |
| next | Yes | |
| slug | Yes | |
| notFor | No | |
| phases | No | |
| source | Yes | |
| install | Yes | |
| related | No | |
| updated | Yes | |
| useWhen | No | |
| category | Yes | |
| oneLiner | Yes | |
| canonical | Yes | |
| definition | No | |
| keyConcepts | No | |
| examplePrompts | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, lowering the bar. The description adds genuinely useful behavioral context beyond annotations: the ~300 token cost estimate, the sections widening behavior including the 'all' shortcut, and the explicit statement of what is NOT returned (skill instructions). No contradiction with annotations.
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?
Three sentences, zero filler. The opening sentence establishes purpose, the second adds the cost rationale and the sections mechanic, the third disambiguates from load_skill. Each sentence is front-loaded and earns its place.
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?
For a metadata-retrieval tool with an output schema, 3 documented params, and strong annotations (readOnly, idempotent), the description covers purpose, usage context, cost behavior, section semantics, and sibling differentiation. The output schema handles return values, so nothing essential is missing.
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 all 3 parameters are documented. The description adds value beyond the schema by explaining the sections param usage pattern ('Pass sections to widen, or sections:[all]'), which the enum list alone doesn't convey. It also contextualizes slug examples indirectly. Slightly above baseline due to the practical 'all' guidance.
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 uses a specific verb+resource ('Metadata for one skill or journey') and enumerates exact content (definition, when to use, when not to, related slugs). It explicitly distinguishes itself from siblings with 'This does not return the skill instructions — load_skill does,' differentiating clearly from load_skill and get_journey.
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 explicit when-to-use guidance: 'cheap (~300 tokens) so you can check a candidate before committing context to it' clearly frames the use case. It also names the alternative (load_skill) for skill instructions, giving concrete when-not-to direction, and explains how to widen results with sections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
load_skillLoad skill instructionsAThe skill's actual instructions — the upstream SKILL.md, ready to follow in this session with nothing installed. The response also lists the skill's reference files with their token cost, so you can pull deeper material on demand by calling again with part set to a filename.
| Name | Required | Description | Default |
|---|---|---|---|
| part | No | "core" (default) for SKILL.md, or a reference filename from a previous response | |
| slug | Yes | Skill or journey slug | |
| context | Yes | Why are you calling this tool? One line on the user's actual task, in their words — not a restatement of the tool name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds value by explaining that the tool not only provides instructions but also lists reference files with token costs, and that further calls can retrieve specific files. This goes beyond the annotations without contradicting them.
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?
Two sentences, front-loaded with the core purpose, zero filler. The second sentence efficiently conveys the extra capability (pulling reference files) without verbosity.
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?
For a read-only retrieval tool, the description fully covers the response contents (skill instructions + reference files with token costs) and the usage pattern (set part to a filename). Annotations confirm safety, so no further behavioral disclosure needed.
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 covers 100% of parameters, so baseline is 3. The description adds value by clarifying the default behavior of 'part' (core SKILL.md) and the workflow of re-calling with a reference filename for deeper material, reinforcing the schema's meaning.
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 specifies the verb (load), the resource (skill instructions), and the exact scope ('ready to follow in this session with nothing installed'). It also distinguishes from siblings by clarifying that this returns the skill's actual instructions for immediate use, not just metadata like get_skill or get_journey.
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?
States when to use (to follow the skill's instructions) and explains the two-step workflow (load core, then call again with part set to a filename for deeper material). It doesn't explicitly mention when NOT to use or name sibling tools, but the context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_skillsRecommend skills for a taskARoute a task to the right skills. Describe the job in your own words and this returns which skills to load first, which to skip whenever a skill's own "not for" line rules it out for this task — quoted verbatim — and a guided journey when the task spans a whole project rather than one step. This is the tool to reach for first.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | How many skills to return (default 3) | |
| task | Yes | The job to be done, in your own words — a full sentence beats a keyword | |
| phase | No | Where in the work you are | |
| stack | No | Language, framework or platform, if it narrows the answer | |
| context | Yes | Why are you calling this tool? One line on the user's actual task, in their words — not a restatement of the tool name. |
| Name | Required | Description |
|---|---|---|
| next | Yes | |
| task | Yes | |
| then | Yes | |
| avoid | Yes | |
| journey | No | |
| loadFirst | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds substantial behavioral detail beyond these flags: it explains the skip logic based on a skill's own 'not for' line, that exclusions are quoted verbatim, and that a guided journey is returned for project-level tasks. This clarifies output structure and decision-making, going beyond what annotations convey.
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?
Three concise sentences, each adding value: the main action, the specific outputs, and a usage directive. Front-loaded with the core purpose, no fluff or repetition. The description is tightly packed and efficient.
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 output schema exists and annotations are rich, the description covers the essential behavioral contract (what it returns, when to use it, and how it handles task scope). It doesn't detail each parameter's role, but that's already in the input schema. The only minor gap is not explicitly mentioning that context, phase, and stack are used to narrow results, but schema descriptions fill that need. Overall, adequate for the tool's simplicity.
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 all five parameters already have clear definitions. The description reinforces the task parameter ('Describe the job in your own words') but adds no new semantic meaning beyond the schema. Per the rubric, baseline 3 is appropriate when schema fully covers 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 a specific verb+resource ('route a task to the right skills') and details what the tool returns (which skills to load first, which to skip, and a guided journey for project-level tasks). It clearly differentiates from sibling tools by positioning itself as 'the tool to reach for first,' so it stands apart from get_journey, get_skill, load_skill, and search_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 explicitly says 'This is the tool to reach for first,' giving a clear directive on when to use it (as the initial step for any task). It also hints at when a different response is expected ('when the task spans a whole project') without needing to name alternatives, as the first-step context makes the usage pattern evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_skillsSearch skillsASearch 50 book-based agent skills and 12 guided journeys by keyword or phrase. Each skill is matched against its own trigger text, so plain task language works ("my UI looks amateur", "pricing", "dark mode"). Returns compact hits, each quoting the line that matched. Use recommend_skills instead when you have a task rather than a keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Restrict to single skills or guided journeys | |
| limit | No | Maximum hits (default 8) | |
| query | Yes | Keyword, phrase, slug or plain description of the problem | |
| context | Yes | Why are you calling this tool? One line on the user's actual task, in their words — not a restatement of the tool name. | |
| category | No | Restrict to one domain |
| Name | Required | Description |
|---|---|---|
| next | Yes | |
| query | Yes | |
| total | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description adds substantial behavioral detail: matching is against trigger text, results are 'compact hits' that quote the matching line, and the search covers a fixed corpus of 50 skills and 12 journeys. This tells the agent what to expect from results and how matching works, with no contradiction of annotations.
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?
Three sentences, each earning its place: scope, matching behavior, and alternative tool guidance. No redundant restatement of the tool name or schema content; the description is front-loaded with the action and resource.
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 moderate complexity, the description covers all essential aspects: what is searched, how matching works, what output looks like, and when to use a sibling tool instead. The output schema and rich annotations fill remaining gaps, making this complete for an agent to select and invoke correctly.
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 the baseline is 3, but the description adds value by explaining query semantics ('plain task language works') and providing concrete query examples ('my UI looks amateur', 'pricing', 'dark mode'). It does not detail kind/limit/category beyond the schema, but the added query guidance justifies a slight uplift.
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 opens with a specific verb ('Search') and a concrete resource ('50 book-based agent skills and 12 guided journeys'), immediately distinguishing it from sibling tools that fetch or load individual items. It also clarifies the matching mechanism ('matched against its own trigger text'), further pinning down exactly what this tool does.
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?
It explicitly names the primary alternative: 'Use recommend_skills instead when you have a task rather than a keyword.' It also provides examples of when search_skills is appropriate ('plain task language works') versus keyword-based queries, giving the agent clear decision criteria without requiring sibling tool inspection.
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.
No comments yet. Be the first to start the discussion!