Search 10,000+ consulting frameworks, templates, financial models, and management case studies
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.7/5 across 5 of 5 tools scored.
Each tool targets a distinct action: searching the catalog, retrieving item metadata, previewing slides, listing topics, and deep-diving into a single topic. No two tools serve the same purpose; even list_topics and get_topic_details are clearly differentiated by scope (all topics vs one topic).
All tools follow a verb_noun pattern with snake_case: get_content_details, get_slide_deep_dive, get_topic_details, list_topics, search_content. The verbs (get, list, search) are appropriate for their actions and consistent throughout.
With 5 tools, the set is well-scoped for a content marketplace, covering search, retrieval, preview, and topic exploration without redundancy. It fits comfortably within the ideal 3-15 range and each tool earns its place.
The tools cover the full discovery journey: browse topics, search content, get detailed metadata, and preview slides. There are no critical gaps for the marketplace's purpose; even author and related topic information are accessible through existing tools, so the workflow has no dead ends.
get_content_detailsGet Content DetailsAFull metadata for one Flevy item, by content_id from search_content (e.g. "doc-1234" or "case-567"). Documents return the author with their credentials (headline, bio, LinkedIn, profile URL; pass the author name to search_content's author filter to list more of their documents), full description, editor summary, AI summary, and editorial review when available, page/slide count, price, FlevyPro inclusion, management topics, ranking badge, and the number of slide deep dives available. Case studies return the client situation, TL;DR, and summary. Call this before recommending an item so you can describe it accurately and cite the author's credentials, and share the returned flevy.com URL.
| Name | Required | Description | Default |
|---|---|---|---|
| content_id | Yes | The content_id from search_content: "doc-<n>" for documents, "case-<n>" for case studies. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral detail by enumerating exactly what fields are returned for documents vs. case studies, including author credentials, summaries, pricing, and the flevy.com URL. This goes beyond annotations to set expectations.
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, well-organized sentence that front-loads the core purpose, then breaks down details by content type. It packs much information without redundancy, earning its length.
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?
With no output schema, the description carries the full burden of explaining return values. It covers both document and case study metadata, mentions the returned URL, and provides usage context, making it highly complete for the tool's complexity.
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% and the schema description already explains the content_id format ('doc-<n>' or 'case-<n>'). The description only repeats the example, adding no extra semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
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 it retrieves full metadata for one Flevy item by content_id, distinguishing it from sibling tools like search_content (search) and get_slide_deep_dive (deep dives). It specifies the resource and the verb 'get' with a clear scope.
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?
Explicitly instructs to call this before recommending an item and explains how to use the returned author name with search_content. This provides clear when-to-use guidance and differentiates from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_slide_deep_diveGet Slide Deep DiveASlide-by-slide preview of a Flevy document (a "doc-" content_id). Returns every showcased slide with its name, a text description of what the slide contains (you cannot see the image, so use the description), a preview image URL, and a deep link to that slide on flevy.com. Use when a user wants to know what is inside a specific presentation before purchasing, or to reference an individual slide. Only some documents have deep dives; get_content_details reports the count.
| Name | Required | Description | Default |
|---|---|---|---|
| content_id | Yes | A document content_id from search_content, e.g. "doc-1234". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral nuances beyond the readOnlyHint annotation: the agent is told it cannot see images and must rely on text descriptions, and it discloses that only some documents have deep dives. This directly informs the agent's expectations and handling.
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, consisting of two sentences that efficiently convey the tool's purpose, return content, usage context, and a caveat. It is well-structured with the most critical information front-loaded.
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?
With no output schema, the description fully explains the return fields (slide name, description, preview URL, deep link) and the practical note about using text descriptions. It also covers the preconditions (only some docs have deep dives) and how to check them, making it complete for a simple tool.
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% with a clear description for content_id ('A document content_id from search_content, e.g. "doc-1234"'). The tool description simply repeats this format ('a "doc-<n>" content_id') without adding new meaning, so it does not exceed the baseline of 3.
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: 'Slide-by-slide preview of a Flevy document' and lists exactly what it returns. It distinguishes itself from siblings by focusing on slide-level content rather than document or topic details.
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?
Explicit usage guidance is provided: 'Use when a user wants to know what is inside a specific presentation before purchasing, or to reference an individual slide.' It also points to an alternative tool, get_content_details, for checking whether a deep dive exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_topic_detailsGet Management Topic OverviewAAn end-to-end overview of one management topic: its definition, an in-depth explanation of the discipline, the 3 editor-curated top documents, all known aliases, document and case study counts, related topics, and the topic page URL. Use this to survey a discipline before going deep — e.g. "what does Digital Transformation cover and what are its key frameworks" — or to orient when the user describes a broad problem area. Follow with search_content (topic filter) for the full catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The management topic or any of its aliases, e.g. "Digital Transformation" (see list_topics). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read nature is covered. The description adds transparency beyond annotations by specifying that it returns exactly 3 editor-curated documents, all known aliases, counts, related topics, and the page URL—details that clarify the tool's behavioral scope and completeness expectations.
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 two sentences, front-loaded with the core purpose ('An end-to-end overview of one management topic'), followed by a concise list of contents and usage guidance. Every clause provides useful information, with no redundancy or filler.
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 simplicity (1 parameter, no output schema) and existing annotations, the description fully covers what the tool returns and when to use it. It enumerates all return elements, provides a concrete example, and suggests an appropriate follow-up action, leaving no significant gaps for an agent to invoke it 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?
The schema already provides a descriptive explanation for the 'topic' parameter, including aliases and a reference to list_topics, achieving 100% schema description coverage. The tool description does not add any additional parameter-level detail beyond restating that it works for 'one management topic,' so it meets the baseline but adds 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 clearly states that the tool provides 'an end-to-end overview of one management topic' and enumerates its exact contents (definition, explanation, 3 top documents, aliases, counts, related topics, URL). It distinguishes itself by advising to 'survey a discipline before going deep' and explicitly names 'search_content' as a follow-up, aligning with sibling differentiation.
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: 'Use this to survey a discipline before going deep' and 'or to orient when the user describes a broad problem area.' It also provides a clear alternative/next step: 'Follow with search_content (topic filter) for the full catalog,' satisfying the requirement for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_topicsList Management TopicsAThe canonical list of management topics Flevy's catalog is organized under, each with its known aliases (e.g. "Digital Transformation" and "Digital Transformation Strategy" may be the same topic) and content counts. Use this to map a user's phrasing to the exact topic filter accepted by search_content, or to show what subject areas Flevy covers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond this: it reveals that the list is 'canonical', includes known aliases (with a concrete example), and supplies content counts, all of which affect how the agent might use the output. It doesn't describe pagination or ordering, but for a zero-parameter read-only list, the transparency is strong.
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 deliver full purpose, usage guidance, and key output details without redundancy. The description is front-loaded with the essential 'canonical list' concept and wastes no words.
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?
With no parameters and a simple list result, the description covers the essentials: what is returned (topics with aliases and counts), why it matters (canonical mapping), and how it connects to sibling tools. The absence of an output schema is compensated by the description's explicit mention of output contents and aliases, making the tool's behavior well understood.
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 has no parameters (100% coverage, 0 params). The baseline for zero parameters is 4, and the description provides no misleading parameter information. It appropriately focuses on the tool's output and uses cases rather than parameter details, which are nonexistent.
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 identifies the tool as returning 'the canonical list of management topics' with aliases and content counts. It uses a specific verb ('list') and resource ('management topics'), and explicitly distinguishes its role from search_content by noting it returns the topic filter. This is a model of clarity.
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?
Explicitly states two concrete use cases: mapping user phrasing to the exact topic filter for search_content, and showing Flevy's subject areas. It also implicitly differentiates from sibling tools like search_content and get_topic_details, providing clear guidance on when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_contentSearch Flevy ContentASearch Flevy's marketplace of consulting frameworks, PowerPoint templates, Excel financial models, business toolkits, and management case studies. Use this whenever a user needs a best-practice framework, methodology, template, financial model, or real-world case example on any business or management topic (strategy, digital transformation, supply chain, pricing, operational excellence, M&A, etc.). Returns up to 10 relevance-ranked recommendations across two content types: "document" (premium documents authored by management consultants) and "case_study" (management case studies). ALWAYS include each recommended item's url as a clickable link when you mention it in your reply — never reference a document without its link, because the link is the only way the user can open it. Each result carries a content_id for get_content_details. Filters: topic (single, or "topics" for documents covering ALL of several topics), author (list more documents from an author seen in results), filetype (including tier1_consulting_deck for McKinsey-style strategy decks), content_type. Topic-filtered responses also list related_topics to pivot to. Provide at least one of query, topic(s), or author; use list_topics to map user phrasing to a canonical topic.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Free-text search, e.g. "balanced scorecard", "post-merger integration checklist", "DCF model". Optional when topic or author is provided (returns their top content). | |
| topic | No | Optional management topic filter, e.g. "Digital Transformation". Accepts any known alias (see list_topics). | |
| author | No | Optional author filter — the author name exactly as shown in document results. Use to list other documents from the same author, alone or combined with a topic. Documents only. | |
| topics | No | Optional: up to 3 topics; returns documents associated with ALL of them (intersection), e.g. ["Digital Transformation","Supply Chain Analysis"]. Documents only. | |
| filetype | No | Optional file-type filter (documents only). Rules of thumb: frameworks, methodologies, and presentation templates are powerpoint; financial models are excel; tier1_consulting_deck = presentations crafted in the style of tier-1 consulting firms (McKinsey/MBB) with the headline-body-bumper slide structure — use it when the user wants consulting-grade frameworks or decks; flevypro = documents included with a FlevyPro subscription. | |
| content_type | No | Optional filter. Default: both types, documents first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, the description adds valuable behavioral traits: returns up to 10 relevance-ranked recommendations, includes two content types, mandates that URLs must be included as clickable links, and notes that topic-filtered responses list related_topics. It also explains content_id usage for get_content_details. This is rich behavioral disclosure that goes well beyond the annotation.
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?
Although the description is relatively long, every sentence adds critical operational detail. It is well-paced: starts with purpose, then usage, then result behavior, then filters, and ends with search prerequisites. The structure is logical and fully utilizes the word budget without redundancy.
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 search tool with six optional parameters and no output schema, the description covers all necessary aspects: input constraints, result format, link requirements, related_tools, and filter behaviors. It is complete enough for an agent to invoke the tool correctly in a wide variety of user queries.
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%, but the description adds significant operational semantics: topics intersection behavior, author exact-match requirement, filetype rules of thumb (e.g., tier1_consulting_deck = McKinsey-style), and default content_type behavior. These details are not in the schema descriptions and help the agent choose and combine parameters correctly.
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 purpose: "Search Flevy's marketplace of consulting frameworks, PowerPoint templates, Excel financial models, business toolkits, and management case studies." It uses a specific verb and resource, and distinguishes itself from siblings by mentioning content_id for get_content_details and related_topics. This is a clear, non-tautological purpose statement.
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 explicit when-to-use guidance: "Use this whenever a user needs a best-practice framework, methodology, template, financial model, or real-world case example..." It also gives operational rules such as "Provide at least one of query, topic(s), or author" and points to list_topics for topic mapping. While it doesn't mention all siblings, it clearly frames when this search tool is appropriate versus specialized follow-up tools.
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!