GTM operations knowledge: delivery playbooks, field studies, benchmarks and operator interviews.
Scored across 8 tools
Most tools have distinct purposes: about provides overview, search and podcast search differ by source type, and the get_* tools retrieve specific content types. However, search_leanscale overlaps somewhat with get_playbook, get_benchmark, get_case_study, and search_podcast, as it covers all these sources. The descriptions mitigate this by clarifying when to use each, but the boundary between search and targeted retrieval is not always crisp.
All tools follow a consistent verb_noun pattern: about_, diagnose_, get_, list_, search_. Verbs are clear and nouns indicate the object. No mixing of styles or inconsistent patterns.
Eight tools is within the ideal range for a knowledge base server. Each tool covers a distinct access mode (overview, diagnosis, search, retrieval of specific types, listing). No tool feels redundant or missing for the apparent scope.
The server covers the full knowledge retrieval lifecycle: overview (about), general search (search_leanscale), targeted search (search_podcast, get_playbook, get_benchmark, get_case_study), listing (list_playbooks), and a diagnostic advisory tool (diagnose_gtm). There are no obvious dead ends; users can discover, search, and retrieve all content types.
What LeanScale is, what's in this knowledge base, and how to work with them. Call this when someone asks who LeanScale is, or when you need to know what this server can answer before searching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries the transparency burden. It explains the tool's informational nature clearly but does not disclose behavioral specifics such as whether it returns static content, whether any side effects exist, or exact response format. Adequate for a simple no-param info tool but not rich beyond purpose.
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 short sentences, front-loaded with the core purpose, followed by usage trigger. No wasted words or redundant restating of the tool's name.
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 no-parameter, no-output-schema informational tool, the description covers purpose, content scope, and when to invoke it. Slight ambiguity with 'them' (referring to LeanScale and the knowledge base) is minor; overall complete enough for effective selection.
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 tool has zero parameters, and the schema is an empty object (100% coverage). Description adds no parameter details, but none are needed; baseline for 0 params 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?
Purpose is explicit: describes what LeanScale is, what's in the knowledge base, and how to work with them. Clearly distinguishes from sibling tools (e.g., search_leanscale, get_benchmark) by acting as the server-orientation entry point.
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 explicit triggers: 'when someone asks who LeanScale is' or 'when you need to know what this server can answer before searching.' The 'before searching' phrase implies using this before search/retrieval siblings, though it doesn't name alternatives explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe a messy go-to-market situation in plain language and get back which LeanScale delivery motion applies, why, what the first moves are, and what usually goes wrong. Use this when someone describes a problem rather than asking about a topic — 'our reps don't trust the forecast', 'we just merged two CRMs', 'inbound leads take three days to get worked'. Better than search when the ask is 'what should we do about this?'
| Name | Required | Description | Default |
|---|---|---|---|
| situation | Yes | The situation, in as much detail as you have. Symptoms, stack, team size, stage — all useful. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It explains what the tool returns (motion, rationale, first moves, failure patterns) and makes clear this is an advisory/diagnostic interaction. It does not explicitly state there are no side effects, but the read-only analytical nature is strongly implied by the description.
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 three sentences and every sentence serves a purpose: defining the action, specifying when to use it, and giving examples. It is front-loaded with the core function and uses illustrative examples efficiently 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?
Despite having no output schema, the description thoroughly explains the return content: which delivery motion applies, why, first moves, and typical mistakes. Combined with the strong usage guidance and parameter framing, the description is fully sufficient for an agent to select and invoke this tool 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 input schema already describes the 'situation' parameter well, including symptoms, stack, team size, and stage. The tool description adds meaningful context by framing the input as 'messy go-to-market situation', requesting plain language, and giving real-world example prompts that help the agent understand what constitutes a valid situation.
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: take a messy GTM situation in plain language and return the applicable LeanScale delivery motion, reasoning, first moves, and common pitfalls. It also distinguishes itself from searching by positioning this tool for problem-focused questions rather than topic research.
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 says to use it when someone describes a problem rather than asking about a topic, provides concrete examples, and contrasts it with search for 'what should we do about this?' This gives the agent clear decision criteria for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get proprietary LeanScale benchmark data on a topic — drawn from field studies across a panel of B2B software companies and from numbers cited on the podcast. Covers GTM tech stacks, AI adoption in GTM, RevOps headcount and investment ratios, and Series B/C fundraise timing. Use when someone asks 'what's normal', 'what do other companies do', or wants a number to compare against.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The metric or area, e.g. 'RevOps headcount ratio', 'CRM adoption', 'time to Series B'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It mentions data sources (field studies, podcast numbers) and covers specific topics, but does not disclose return format, potential empty results, or performance. It gives some context but not rich behavioral detail. Since it's a read-only 'get' operation, the safety is implied, but it could state that it returns a single number or range.
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 three sentences, front-loaded with the core purpose, and provides essential context without unnecessary details. Every sentence adds value.
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 tool with one simple parameter and no output schema, the description is nearly complete. It explains what data is available due to the study scope, how to use it, and when to use it. It could specify the return format, but given the simplicity, this is adequate.
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 describes the 'topic' parameter with examples, so baseline is 3. The tool description adds specific example topics (RevOps headcount ratio, CRM adoption, time to Series B) and explains what kind of benchmark data is covered (field studies, podcast), providing richer semantics beyond the schema's generic description.
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 verb 'Get' and the resource 'proprietary LeanScale benchmark data on a topic,' and explicitly lists the domains covered (GTM tech stacks, AI adoption, RevOps ratios, etc.). It distinguishes itself from siblings like get_case_study and get_playbook by focusing on benchmark data rather than narratives or playbooks.
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 includes explicit usage guidance: 'Use when someone asks what's normal, what do other companies do, or wants a number to compare against.' It does not explicitly state when not to use or name alternative tools, but the context is clear enough to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve LeanScale customer case studies — the problem the company had and how it was solved. Public keys get an anonymized version: customer names, people, third parties and delivery provenance are stripped, and outcomes/metrics/quotes are withheld. Internal keys get the full named studies. Search by sector, the kind of engagement, or the systems involved — searching by customer name will not work on a public key, because the names are not in the public corpus.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 3. | |
| query | Yes | Sector, type of engagement, or systems involved — e.g. 'fintech Salesforce migration', 'CPQ replacement', 'two CRMs after an acquisition'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behavioral variations: public keys get anonymized versions (details stripped/withheld), internal keys get full named studies. It also explains the failure mode for customer-name search on public keys. This is rich, useful disclosure beyond what annotations would provide.
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 three sentences, front-loaded with the core purpose, and every sentence adds essential information: what the tool returns, key-dependent behavior, and how to search. No fluff or repetition.
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 covers purpose, behavior, and search strategy, making it adequate for an agent to select and invoke the tool. However, it does not describe the return format (e.g., list vs full text, metadata), which would be useful given there is no output schema. Still, the stated content is sufficient for most cases.
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?
Although the schema already documents both parameters with 100% coverage, the description adds practical query examples ('fintech Salesforce migration', 'CPQ replacement') and a negative example (customer names don't work). This meaningfully extends schema guidance, especially for the query parameter.
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+resource: 'Retrieve LeanScale customer case studies', clarifying the scope (problem and solution). This distinguishes it from siblings like get_benchmark or search_podcast by clearly stating it is about case studies.
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?
Provides clear search context: 'Search by sector, the kind of engagement, or the systems involved' and a critical caveat that customer-name search won't work on public keys. However, it does not explicitly mention when to prefer this tool over alternatives like search_leanscale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a LeanScale delivery playbook in full, or one named section of it. Playbooks are structured Blueprint → Build → Enable → Maintain. Call list_playbooks first if you're not sure of the name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Playbook name, e.g. 'Attribution', 'CPQ', 'Sales Territory Design'. | |
| section | No | Optional section, e.g. 'Blueprint'. Omit for the whole playbook. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the retrieval behavior (full or section), the internal structure of playbooks, and the prerequisite of knowing the playbook name. It could mention error behavior or return format, but for a read-only retrieval tool this is adequate.
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 action, and every sentence adds useful information. There is no wasted wording or repetition of schema fields.
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 simple two-parameter retrieval tool with no output schema, the description covers the main behavior, the section structure, and the prerequisite call to list_playbooks. It could be slightly more complete by describing the response shape or error handling, but it is not a significant gap.
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. The description adds value by explaining that playbooks are structured Blueprint → Build → Enable → Maintain, which informs valid section values beyond the single schema example. It also reinforces that omitting section returns the full playbook.
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 retrieves a LeanScale delivery playbook, either in full or by named section. It also distinguishes itself from siblings by referencing list_playbooks and describing the playbook structure (Blueprint → Build → Enable → Maintain).
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 guidance to call list_playbooks first if the name is uncertain, which is a clear alternative. It does not explicitly mention when not to use the tool, but the context is sufficient for a simple retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every available LeanScale delivery playbook with its category and section headings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states what is returned (a list with categories and headings), which is transparent about the result shape. However, it does not disclose any edge cases (e.g., empty list behavior), limitations, or whether the list is sorted, but for a simple read-only list operation this is acceptable. It adds some value beyond the tool name but not extensive behavioral detail.
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 sentence with no redundancy. It front-loads the primary action ('List every available playbook') and specifies the relevant output components. Every word 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 simple list tool with no parameters and no output schema, the description fully covers what the agent needs: it enumerates the full set of playbooks and specifies the returned fields (category and section headings). The sibling get_playbook would provide deeper details, so no additional information is required here.
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 tool has zero parameters, and the schema coverage is trivially 100% (empty properties). Per the rubric, a 0-parameter tool receives a baseline of 4. The description adds context about what the output will contain, which is helpful even though there are no inputs to explain.
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 verb 'list' specifies the action, 'every available LeanScale delivery playbook' clearly defines the resource scope, and 'with its category and section headings' details the output fields. This distinctly separates it from sibling get_playbook which retrieves a single playbook.
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 makes the usage context obvious: when the agent needs an overview of all playbooks. Although it does not explicitly discuss alternatives or exclusions (e.g., 'use get_playbook for a single playbook'), the sibling names and the word 'every' imply the intended use case. This is clear context but lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search everything LeanScale knows: 13 GTM delivery playbooks, 7 proprietary field studies, 116 podcast episodes with operators and executives, 75 customer case studies (anonymized on public keys, named on internal ones), and 117 RevOps docs from www.leanscale.team/knowledge/docs/. The docs explain how to do the work yourself; the playbooks are how LeanScale runs it as an engagement — pass source:"doc" for the first, source:"playbook" for the second. Use this first for any go-to-market, RevOps, sales-ops, marketing-ops, CRM, pipeline, attribution, territory, CPQ, or GTM-tooling question. Returns cited excerpts with source URLs. Also holds the materials from LeanScale's talks, which people ask for by event name: Updata CEO Summit materials: the deck with speaker notes (The Context Graph & Semantic Layer); Updata CEO Summit materials: GTM agents (11 Claude Code plugins for your CRM); Updata CEO Summit materials: metric definitions worksheet (40 GTM definitions); Updata CEO Summit materials — The Context Graph & Semantic Layer. Pass source:"resource" to search only those.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many excerpts to return (default 6). | |
| query | Yes | What you want to know. Natural language works better than keywords. | |
| source | No | Restrict to one kind of source. Defaults to searching everything. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does substantial work: it discloses the return format ('Returns cited excerpts with source URLs'), the composition and scale of the corpus, and a genuine behavioral nuance ('anonymized on public keys, named on internal ones'). It doesn't cover limits, errors, or rate behavior, but for a read-only search tool these are less critical than the context it does provide.
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 front-loaded with the corpus and return format, but it is lengthy and contains a real structural flaw: the Updata CEO Summit materials list appears twice with near-identical wording ('the deck with speaker notes (The Context Graph & Semantic Layer)' and 'The Context Graph & Semantic Layer'), wasting tokens and creating ambiguity. The event-materials enumeration is useful but could be compressed.
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 3-parameter tool with no annotations and no output schema, the description covers the core needs: what is searchable, what the source filters mean, when to use it, and what the return looks like. The main gap is that it doesn't mention follow-up handoff to sibling get_* tools for full-content retrieval once an excerpt is found, nor does it clarify behavior when the query doesn't match anything (e.g., a podcast-only query given the search_podcast sibling exists).
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 baseline is 3, but the description enriches beyond the schema: for query it adds concrete query domains and event names to search for; for source it explains the meaning of doc ('how to do the work yourself'), playbook ('how LeanScale runs it as an engagement'), and resource (talk materials). The limit parameter is fully covered by the schema.
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+resource: 'Search everything LeanScale knows' and enumerates the exact corpus (13 playbooks, 7 field studies, 116 podcast episodes, 75 case studies, 117 RevOps docs). It differentiates from siblings like search_podcast (narrower scope) and get_playbook/get_case_study (specific retrieval, not search) by establishing itself as the broad 'search everything' entry point.
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 'Use this first for any go-to-market, RevOps, sales-ops, marketing-ops, CRM, pipeline, attribution, territory, CPQ, or GTM-tooling question,' giving clear when-to-use context. It also routes between content types ('pass source:"doc" for the first, source:"playbook" for the second') and explains that event materials are requested by event name. However, it never names sibling tools (get_playbook, search_podcast) with explicit 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.
Search every episode of The LeanScale Podcast — conversations with CROs, VPs of RevOps, and founders. Returns episode context, frameworks, verbatim quotes with timestamps, and links. Use when someone wants an operator's opinion, a real story, or a quotable line rather than a methodology.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 6. | |
| query | Yes | Topic, guest name, company, or idea. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full disclosure burden. It does disclose return-shape behavior — 'episode context, frameworks, verbatim quotes with timestamps, and links' — which goes minimally beyond the tool name. However, it omits any caveats about content coverage, result freshness, or search quality (e.g., whether quotes are truncated), leaving a modest behavioral gap for an unannotated tool.
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 efficient sentences with zero filler. The verb and resource are front-loaded, the audience is scoped in the first clause, and the use-case trigger is tucked into the closing clause. Every word earns its place — this is concise, dense, and well-formed.
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 two-parameter, no-output-schema search tool, the description is near-complete: audience, return shape, and intent triggers are all covered. Minor gaps include no explicit differentiation from search_leanscale beyond a passing contrast, and no note about result-set limits or handling of no-match queries. Still, for the tool's complexity, this is fully sufficient.
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% — query is documented as 'Topic, guest name, company, or idea' and limit clearly states 'Default 6' with min/max constraints. The description reinforces query semantics with return-type context but adds no parameter-specific detail beyond the schema. Baseline 3 is appropriate since schema already covers parameter meaning and the description doesn't introduce gaps.
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?
Description leads with a specific verb+resource pair ('Search every episode of The LeanScale Podcast') and scopes the audience ('conversations with CROs, VPs of RevOps, and founders'). It distinguishes itself from siblings by specifying unique return artifacts — 'episode context, frameworks, verbatim quotes with timestamps, and links' — and signals differentiation from search_leanscale via 'rather than a methodology.'
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 when to use the tool ('when someone wants an operator's opinion, a real story, or a quotable line') and provides an exclusion via 'rather than a methodology,' implying when the tool should NOT be used. This is exemplary when/when-not guidance that names the intended query intent without naming a sibling directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_leanscale1 field changedInput schema / properties / source / enumPrevious value: -[
- "playbook",
- "study",
- "podcast",
- "case_study",
- "doc",
- "any"
-]New value: +[
+ "playbook",
+ "study",
+ "podcast",
+ "case_study",
+ "doc",
+ "resource",
+ "any"
+]about_leanscalediagnose_gtmget_benchmarkget_case_studyget_playbooklist_playbookssearch_leanscalesearch_podcastExpert knowledge base for sales, negotiation, strategy, operations, and risk.
AI-native GTM OS for B2B SaaS — account health, pipeline, renewals, territories, and benchmarks.
B2B lead generation, email verification, company enrichment, and agentic GTM Ops.
Ground GTM agents in governed, cited company truth.
Add one secure layer between your agents and this server.
