Independent weekly on AI in B2B revenue teams: articles, frameworks, skills, playbooks, datasets.
Scored across 23 tools
The get_/list_ pairs are clearly separated by resource type, and the descriptions consistently specify what each returns. Minor ambiguity exists between get_resource and the specialized get_* tools, and search_site overlaps with search_publications and search_tools, but the descriptions provide enough guidance to choose correctly.
Tool names follow a consistent snake_case verb_noun pattern: get_ for single items, list_ for collections, and search_ for queries. The pattern is predictable across all 23 tools, with lookup_term as the only mild variation but still in the same style.
23 tools is slightly heavy, but the server covers a large content ecosystem with many distinct resource types, each needing list/get/search access. The count is justified by the scope, though it is near the upper edge of where a well-scoped toolset typically sits.
The toolset covers the full read-side lifecycle for every public resource type: browse, read, search, and orientation. It even includes glossary lookup, resource-type mapping, and reversal ledger access, leaving no obvious dead ends for an agent exploring the publication.
Read one dataset's description, contents, full column schema, method notes, FAQs, and download URL.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Dataset slug, e.g. proof-gap-index. |
| Name | Required | Description |
|---|---|---|
| dataset | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds value by listing exactly what the read returns, which goes beyond the annotation metadata and helps the agent set expectations for the response.
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, efficient sentence that front-loads the action and resource, then concisely lists the content areas returned. Every phrase earns its place and there is no redundant 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 is a simple single-parameter read operation with a full output schema and strong annotations, the description is largely complete. It could slightly improve by mentioning that the slug should come from list_datasets, but that is a minor gap and likely inferable from the sibling tool set.
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 only parameter, slug, is already fully documented in the schema with a minLength and an example, so schema description coverage is 100%. The tool description adds no new meaning about slug beyond implying it identifies the dataset, which is the expected baseline when the schema carries the parameter details.
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 clearly states the verb 'Read' plus the resource 'one dataset' and enumerates the returned content: description, contents, full column schema, method notes, FAQs, and download URL. This distinguishes get_dataset from list_datasets and other get_* siblings because it is explicitly about fetching a single dataset's full record.
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 basic use case obvious: use this when you need the full details of one known dataset. However, it does not mention when not to use it or point to alternatives like list_datasets for discovering dataset slugs, so selection guidance is mostly implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one framework in full, including its definition, sections, related pages, and FAQs.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Framework slug, e.g. proof-gap, scale, lopaft, eight-seats. |
| Name | Required | Description |
|---|---|---|
| framework | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by specifying that the full framework includes definition, sections, related pages, and FAQs, setting expectations for response content without contradicting 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?
Single sentence with no filler, front-loaded with verb and scope, then enumerates contents.
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 one well-documented parameter, output schema present, and annotations covering safety, the description is sufficient for an agent to invoke correctly. No critical gaps.
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% with slug's description including examples. The tool description adds no parameter-level detail, so the schema carries the burden; baseline 3 applies.
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?
States a specific verb 'Read' and resource 'one framework in full', and enumerates contents (definition, sections, related pages, FAQs). This clearly distinguishes it from list_frameworks and other get_* tools by resource type.
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?
No explicit guidance on when to choose this over list_frameworks or other getters. The use case is implied by 'Read one framework in full' – retrieve a single framework – but no alternatives or exclusions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one playbook in full: every step with its owner, tool, pitfalls, and definition of done, plus the KPIs that prove it worked.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Playbook slug, e.g. ai-meeting-notes-l1. |
| Name | Required | Description |
|---|---|---|
| playbook | Yes | |
| relatedSkills | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns the playbook 'in full' and enumerates content elements, which provides some context beyond the bare annotations. However, it does not disclose authentication, rate limits, or error behavior, and the output schema likely already describes the return structure, so the added value is moderate.
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, tightly worded sentence that front-loads the core action ('Read one playbook in full') and then enumerates the included elements without redundancy. Every word earns its place, and no fluff or repetition exists.
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 read-only tool with one parameter, rich annotations, and an output schema, the description is nearly complete: it states the operation, the resource, and the key contents. It does not mention how to discover a slug (e.g., via list_playbooks) or handle not-found cases, but these are minor gaps given the schema and annotations.
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 has 100% coverage: the slug parameter is fully documented with type, requirement, and an example. The description does not add any additional meaning to the parameter, so the baseline of 3 applies as the schema carries the semantic weight.
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 ('Read') and resource ('one playbook'), and explicitly states the scope ('in full') and the contents (every step with owner, tool, pitfalls, definition of done, KPIs). This clearly distinguishes it from sibling tools like list_playbooks (which lists) and other get_* tools for different resources.
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 implies usage when you need complete details of a single playbook, but it does not explicitly mention alternatives or when not to use it. There is no reference to list_playbooks for finding slugs or to other get_* tools for different resource types, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full copy-ready text of one prompt from The Revenue AI Report prompt library, by slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Prompt slug, e.g. prep-for-follow-up. |
| Name | Required | Description |
|---|---|---|
| prompt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive. The description adds behavioral context by specifying that it returns the full copy-ready text of exactly one prompt keyed by slug, which goes beyond the annotations and the schema.
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?
A single, compact sentence leads with the action and resource, then packs the key details (copy-ready text, one prompt, prompt library, slug) with no wasted 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?
For a one-parameter read-only tool with an output schema and strong annotations, the description is fully sufficient. An agent knows what to retrieve, how to retrieve it, and what kind of result to expect.
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?
With only one parameter and 100% schema description coverage, the schema already defines slug and gives an example. The description's 'by slug' adds no new parameter semantics, so the baseline score of 3 applies.
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 names a specific verb ('Get'), resource ('one prompt from The Revenue AI Report prompt library'), and selection mechanism ('by slug'). It also distinguishes from the sibling list_prompts by emphasizing singular retrieval and full copy-ready text.
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 implies when to use the tool (when you have a slug and need the full prompt text) but does not explicitly state when to prefer it over siblings such as list_prompts or how to find the slug. There are no exclusions or alternative-tool routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full text of one published article from The Revenue AI Report by its slug, including body paragraphs and FAQs.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Article slug, e.g. evaluating-sales-gtm-ai-tools. |
| Name | Required | Description |
|---|---|---|
| article | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description only needs to add context beyond that. It adds that the result is the full text of a published article including FAQs, but it does not describe error behavior or access edge cases. This is similar to other annotation-backed read tools.
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?
One tight sentence with no filler. The verb, resource, scope, access key, and content expectations are all front-loaded. Nothing could be removed without losing information.
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 one-parameter read tool with a complete schema, strong annotations, and a provided output schema, the description is fully sufficient. It specifies how to identify the article and what content to expect.
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%: the single slug parameter includes a type, minLength, and a concrete example. The description adds no further meaning about the parameter, so the baseline of 3 applies.
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 ('Get'), the exact resource ('full text of one published article from The Revenue AI Report'), and the access mechanism (by its slug). It also includes return-content highlights ('body paragraphs and FAQs'), which distinguishes it from siblings such as get_publication_info and search_publications.
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 clearly conveys when to use this tool: to retrieve a single article's full text given a known slug. It does not explicitly list when not to use it or name metadata-focused alternatives, but the context is unambiguous and no exclusion is critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an overview of The Revenue AI Report: its mission, editorial pillars, audience, sponsorship policy and article count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| name | Yes | |
| cadence | Yes | |
| mission | Yes | |
| pillars | Yes | |
| audience | Yes | |
| description | Yes | |
| sponsorship | Yes | |
| articleCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not restate these. The description adds value by listing specific content areas (e.g., mission, pillars) and mentions 'article count' which suggests return of statistical data, but does not detail response format or potential limitations.
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, concise sentence that is front-loaded with the main purpose ('Get an overview') and then lists specific items. Every word adds value without fluff.
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 zero-parameter read-only tool with a clear purpose, the description is sufficient. It does not explain return format, but the presence of an output schema likely covers that. The inclusion of 'article count' hints at quantitative output, but no further details are needed for an agent to invoke it successfully.
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?
Since the tool has zero parameters, the schema provides no parameter documentation. The description compensates by listing exactly what information will be returned (mission, pillars, audience, sponsorship, article count), giving the agent a clear expectation of the output.
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 provides an overview of The Revenue AI Report, listing specific aspects like mission, editorial pillars, audience, sponsorship policy, and article count. However, it does not explicitly differentiate from 'get_publication' which may have overlapping functionality.
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 implies the tool is used to get high-level information about the publication, but it does not specify when to use this instead of 'get_publication' or other siblings. There is no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one research theme in full: the opening argument, every chart with its numbers, the findings, the named sources with publisher, sample size, and caveats, and anything still unconfirmed. Cite the source line, not just the chart.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Research theme slug, e.g. proof-gap or task-fallacy. |
| Name | Required | Description |
|---|---|---|
| theme | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing the full payload contents: charts with numbers, named sources with publisher and sample size, caveats, and unconfirmed material. It also adds a specific behavioral instruction to cite the source line rather than just the chart, which is valuable context not present in annotations or schema.
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, front-loaded sentence that begins with the core action and then efficiently lists the contents of the full theme. Every phrase adds meaningful detail, and there is no filler or repetition of the tool name or annotations.
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 single required parameter, full schema coverage, an output schema, and read-only/idempotent annotations, the description covers everything needed to call and interpret the tool correctly. The only use-case nuance is routing to list_research for summaries, but that is not necessary for correctness since list_research is clearly a different sibling 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?
The schema already fully documents the only parameter, slug, with examples and a clear description. The tool description adds the context that this slug identifies a 'research theme', but it does not add new parameter-level meaning beyond what the schema provides. With 100% schema coverage, the baseline 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 starts with 'Read one research theme in full' and then enumerates exactly what is included: opening argument, charts, findings, sources, caveats, and unconfirmed items. This clearly identifies the specific verb, resource, and scope, and distinguishes it from siblings like get_dataset or list_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?
The description makes clear this is for reading a single research theme in full, which implies use when complete detail is needed. It does not explicitly mention alternatives like list_research for overviews or search_publications for finding publications, so it lacks explicit exclusions, but the usage context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the indexed text of any public resource on The Revenue AI Report by its site path or full URL, whatever the type: article, research theme, framework, skill, prompt, playbook, dataset, tool profile, archive issue, ledger row, or definition. Use this when search_site returns a path you want to read in full.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Site path or full URL, e.g. /playbooks/ai-meeting-notes-l1. |
| Name | Required | Description |
|---|---|---|
| path | No | |
| matches | No | |
| resource | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context that the content is 'indexed text' and limited to 'public resources', which clarifies what the agent will get and what access is required. It does not contradict 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?
The description is a single, information-dense sentence. It front-loads the core action and scope, then provides the usage trigger. No filler, and every clause adds value. It is appropriately concise for a simple read tool.
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 (though not shown), the annotations cover safety, and the parameter schema is fully described, the description covers what the tool does, when to use it, and the input format. Nothing critical is missing for an agent to call it correctly. It is complete for a read-only resource fetcher.
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 100% coverage with a description for the single 'path' parameter, including an example. The description reinforces the parameter's format ('site path or full URL') but adds no new semantic detail beyond the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.
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 action (read indexed text) and its resource scope (any public resource on the site, with an explicit list of types). It distinguishes itself from the many type-specific sibling getters by framing itself as a generic path-based reader, so an agent can tell it apart from get_playbook or get_framework without opening their schemas.
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 gives a usage trigger: 'Use this when search_site returns a path you want to read in full.' This tells the agent when to reach for this tool. It does not explicitly state when to prefer the specific getters over this generic one, but the phrasing 'whatever the type' implies it is a catch-all, which is a clear enough routing signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one skill in full, including the copy-ready quick prompt, inputs, process, decision rules, quality checks, limitations, worked example, and the downloadable SKILL.md URL.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Skill slug, e.g. build-ideal-customer-profile. |
| Name | Required | Description |
|---|---|---|
| skill | Yes | |
| relatedTools | Yes | |
| relatedPlaybooks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds value by specifying the exact components returned (e.g., copy-ready quick prompt, SKILL.md URL), which is beyond the annotations and helps the agent understand the scope of the read.
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?
A single, information-dense sentence that front-loads the core action and then lists the deliverable components without redundancy. Every phrase 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 read tool with one parameter, a rich output schema (not shown but indicated), and annotations covering safety, the description fully specifies what is returned. No missing information an agent would need to call 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?
Schema coverage is 100% and the single parameter 'slug' is fully described in the schema with an example. The description adds no additional meaning beyond what the schema provides, so baseline 3 applies.
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?
States a clear verb+resource: 'Read one skill in full' and enumerates the specific content returned (quick prompt, inputs, process, etc.). This distinguishes it from list_skills and other get_* tools by implying it retrieves the complete single skill record.
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?
Implies usage for retrieving full skill details, but does not explicitly contrast with alternatives like list_skills or other get_* tools. No explicit 'when not to use' or naming of sibling tools, leaving some inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one vendor profile in full from The Revenue AI Report AI tool library, by slug or by name. Returns the directory record plus the depth layer: why the adoption effort level is what it is, owning seat and journey stage, buy checks, published case studies, documented discrepancies between vendor claim and independent reporting, corporate status changes, and any Reversal Ledger record naming this vendor.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Tool name, used when the slug is unknown. | |
| slug | No | Tool slug, e.g. clari. |
| Name | Required | Description |
|---|---|---|
| faqs | Yes | |
| tool | Yes | |
| adoption | Yes | |
| evidence | Yes | |
| buyChecks | Yes | |
| placement | Yes | |
| relatedSkills | Yes | |
| reversalLedger | Yes | |
| corporateStatus | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds substantial value by detailing exactly what the depth layer includes (adoption effort rationale, owning seat, buy checks, case studies, discrepancies, corporate changes, Reversal Ledger records). This goes beyond the annotations and clarifies the return content, though it does not describe error handling or absence cases.
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, information-dense sentence. It front-loads the core action and then lists the detailed contents efficiently. There is no filler, though the list of depth-layer items is lengthy; each item earns its place by informing the agent of what to expect.
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 has two optional parameters, an output schema, and annotations covering safety, the description is largely complete. It explains the selection method and the full scope of returned data. It does not mention authentication prerequisites or error responses, but these are not typically required for a read-only lookup tool, and the output schema covers return structure.
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 both name and slug are already documented individually. The description simply restates that selection is 'by slug or by name', which adds no new semantic information. It does clarify that only one of the two is needed, but that is also implied by the schema's 'used when the slug is unknown' note.
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 (get), a specific resource (one vendor profile), and the selection method (by slug or by name). It also enumerates the exact contents of the returned record, making it unmistakably distinct from the many sibling get_* tools which target different resource types.
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 implies this is for retrieving a specific known tool by slug or name, and the sibling list includes search_tools and list_tools for discovery. However, it does not explicitly state when to prefer this tool over alternatives or provide exclusion conditions. Usage context is implied but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the open datasets published by The Revenue AI Report, with what each contains, its column schema, and the download URL. Most are free CSV downloads.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| datasets | Yes | |
| bundleUrl | Yes | |
| datePublished | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the agent knows it's a safe read operation. The description adds that most datasets are free CSV downloads, which is useful but not deeply behavioral. No mention of pagination, output size, or any potential side effects, but given the zero-param and read-only nature, 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, direct, and front-loads the core purpose (listing datasets) before adding details about content and download URL. No filler or redundant phrasing.
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 the key information an agent needs: what is listed (datasets), what each entry includes (contents, schema, URL), and the access type (free CSV download). With an output schema present, the description doesn't need to detail return structure. Minor gap: doesn't clarify whether the list is exhaustive or filtered, but for a zero-param tool this is 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?
Since the tool has zero parameters, there's no schema to describe, making a baseline 4 appropriate. The description doesn't need to add parameter semantics, and it doesn't; it clearly explains what the output contains instead.
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 lists open datasets published by a specific source (The Revenue AI Report), and specifies the content of the listing: what each dataset contains, schema, and download URL. This is specific and distinguishes it from siblings like list_frameworks or list_publications.
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 implies usage for browsing available datasets, but does not state when to prefer this over get_dataset or other list tools. No explicit exclusion or alternative naming, though the 'open datasets' qualifier gives some context. Without entering get_dataset's schema, an agent might not know the difference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the frameworks published by The Revenue AI Report, including the canonical concepts (Proof Gap, Optimization Theater, Reversal Ledger, Eight Seat Read) and the named operating frameworks in the library such as SCALE, OAR, LOPAFT, and the L1 to L6 AI Maturity Ladder.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| seats | Yes | |
| frameworks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description need not restate it. The description adds content-level context about what the returned list contains, which is useful, but discloses no additional behavioral traits such as ordering, pagination, or completeness guarantees. 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?
A single front-loaded sentence that states the core purpose first and then elaborates with concrete examples. The example enumeration adds a little length but earns its place by setting expectations for what counts as a 'framework' in this library. No fluff.
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?
Complete for a zero-parameter, read-only list tool: the output schema covers the return shape, annotations cover safety and idempotency, and the description explains exactly what the list contains. Nothing an agent needs to call it correctly 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?
The tool has zero parameters, so per the rubric the baseline is 4; there is nothing for the description to document. Schema coverage is trivially 100% with an empty object.
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?
States a specific verb (list) and a precise resource (frameworks published by The Revenue AI Report), then disambiguates the scope by naming both the canonical concepts (Proof Gap, Optimization Theater, Reversal Ledger, Eight Seat Read) and the named operating frameworks (SCALE, OAR, LOPAFT, L1–L6 Maturity Ladder). An agent can tell exactly what this returns and how it differs from the get_framework sibling.
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 clear what content is included, which implies a browse-overview use case, but it never explicitly states when to prefer this over get_framework for a single framework, nor names any alternative. Usage context is implied by the list-vs-get sibling pattern rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the GTM AI playbook library from The Revenue AI Report. Each playbook is a sequenced workflow with owner, tool, pitfalls, definition of done, and KPIs, mapped to a team and to an L1 to L6 AI maturity level. Filter by team, maturity level, or keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No | Team or category. One of: cs, enablement, general, marketing, org, revops, sales. | |
| limit | No | Default 30. | |
| query | No | Keyword filter on title, summary, and tags. | |
| maturity | No | AI maturity level, L1 to L6. |
| Name | Required | Description |
|---|---|---|
| teams | Yes | |
| total | Yes | |
| matched | Yes | |
| returned | Yes | |
| playbooks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds useful content context about playbook structure and maturity levels, but does not disclose additional behavioral traits such as auth requirements, rate limits, or pagination behavior beyond what schema already covers.
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 with no filler: purpose, playbook content model, and filter options. It is front-loaded and every sentence earns its place, making it easy for an agent to scan and understand quickly.
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 all four optional parameters are fully documented, the description is largely complete for a read-only list operation. It names the relevant filters and the data domain; only an explicit pointer to get_playbook for single-item retrieval 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 description coverage is 100%, with team, limit, query, and maturity all individually documented. The description's mention of filtering by team, maturity level, or keyword mirrors the schema without adding new syntax or format details, so the baseline 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 opens with a specific verb and resource: 'Browse the GTM AI playbook library.' It further distinguishes itself from sibling list tools by describing the unique playbook structure and naming the three filter dimensions, so an agent can clearly tell it apart from list_prompts, list_resources, and similar tools.
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 clearly implies the tool is for browsing and filtering playbooks by team, maturity, or keyword, but it does not explicitly explain when to choose this over the sibling get_playbook or other list_* tools. Usage context is present, but exclusions and alternative routing are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the public prompt library from The Revenue AI Report. Copy-ready AI prompts for revenue teams, filterable by team, category, or keyword. Use get_prompt to read the full prompt text.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No | Filter by revenue team. | |
| limit | No | Default 30. | |
| query | No | Keyword filter on name and summary. | |
| category | No | Filter by what the prompt does. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| matched | Yes | |
| prompts | Yes | |
| returned | Yes |
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 library is 'public' and 'copy-ready', which gives useful context beyond the structured hints. No contradiction.
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 short, purposeful sentences. The main action is front-loaded, and each sentence adds value: purpose, content/filters, and a sibling pointer. No wasted 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 a complete output schema and 100% parameter coverage, the description provides sufficient guidance for an agent to call it correctly. It clarifies the resource scope and points to the right sibling for full content.
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%, with each parameter already well-documented. The description mentions 'filterable by team, category, or keyword' but adds no syntax or format details beyond what the schema provides. Baseline 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 opens with a specific verb ('Browse') and resource ('public prompt library'), and immediately distinguishes itself from get_prompt by noting that tool reads the full text. This clearly separates it from the many sibling list_* tools.
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 routes users to get_prompt for reading full prompt text, which is the main alternative. While it doesn't mention other list_* tools, the resource-specific naming makes the usage context clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List published articles from The Revenue AI Report, newest first. Returns slug, title, summary, pillar, date and reading time.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of articles to return. | |
| pillar | No | Optional editorial pillar to filter by. |
| Name | Required | Description |
|---|---|---|
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds behavioral details: 'newest first' ordering and the specific return fields (slug, title, summary, pillar, date, reading time), which go beyond the annotations and schema.
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?
A single, well-structured sentence that front-loads the main action and scope, then states ordering and return fields. Every element earns its place with zero 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?
The output schema exists, and the description adds the source report and ordering. Combined with the schema's param definitions and annotations covering safety, nothing essential is missing for an agent to call this 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 description coverage is 100%, with both 'limit' and 'pillar' fully described. The description does not add any parameter-specific meaning beyond what the schema already provides, so a 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?
States the specific verb 'List' and the resource 'published articles from The Revenue AI Report'. Clearly distinguishes from siblings like get_publication (single item) and search_publications (search) by focusing on listing with a defined 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?
The description clearly implies its use for retrieving all publications, but does not explicitly name alternatives or provide when-not-to-use guidance. Sibling tools like search_publications are not mentioned, leaving the routing decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the research themes published by The Revenue AI Report. Each theme is a sourced argument about AI inside B2B revenue teams, with charts, findings, named sources, and sample sizes.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Keyword filter on title, dek, and findings. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| themes | Yes | |
| returned | Yes | |
| researchRules | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds return-content context beyond the annotations by stating that each theme is a sourced argument with charts, findings, named sources, and sample sizes. It does not discuss pagination or ordering, but that is a minor gap given 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff: the first states the action and scope, the second defines the returned item. Every sentence 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 tool with one optional parameter, full annotations, and an output schema, the description provides enough context to call and interpret the result. It defines the domain, the item type, and the item contents, leaving only structured details to the schema.
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% for the single optional 'query' parameter, which is already described as a keyword filter on title, dek, and findings. The description adds no new parameter semantics, but the schema fully covers it, so the baseline of 3 applies.
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 ('List') and resource ('research themes published by The Revenue AI Report'), and further defines what a theme is with content details. This clearly distinguishes the tool from the many sibling list/get/search tools.
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?
No when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives like search_publications, get_research, or list_reversals, leaving the agent to infer selection from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map of every public resource type The Revenue AI Report publishes, how many items each holds, the hub URL, and which tool reads it. Call this to orient before searching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| resources | Yes | |
| totalIndexed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description carries less burden. It adds context by describing the tool as a map of resource types, counts, hub URLs, and tool mappings, which goes beyond a simple list and supports the openWorldHint=false annotation. No contradictions exist.
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 with no fluff. The first sentence front-loads the core content (map, counts, URLs, tool mapping) and the second provides a direct action cue. Every word earns its place, making it appropriately sized for an agent seeking quick orientation.
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 an output schema present and a zero-parameter signature, the description fully specifies what the tool returns and when to invoke it. It also references the broader tool ecosystem ('which tool reads it') without needing to detail return formatting, which the output schema covers. 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?
The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds value by clarifying what the empty call returns (a map of all resource types) and its purpose (orientation), which enriches the null-parameter call beyond generic 'list' semantics.
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 precise outcome: a map of every public resource type, with counts, hub URLs, and the tool that reads each. It distinguishes itself from sibling list_* tools by emphasizing cross-type orientation rather than listing a single type, and from search tools by explicitly positioning it as an orient-before-search step.
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 to call this to orient before searching, giving a clear when-to-use cue. It does not name specific alternative tools, but the instruction to use it before searching implies the differentiation from search_* and other list_* tools, making the context clear without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read The Revenue AI Report Reversal Ledger: named companies that pulled back, paused, or reversed an AI deployment, with the vendor, function, seat, dates, disclosed cost, stated reason, and the public source for each record.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 50. | |
| query | No | Keyword filter on company, vendor, function, or reason. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| csvUrl | Yes | |
| records | Yes | |
| returned | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds value by specifying the scope: it returns 'named companies' and includes a 'public source for each record', which implies transparency and traceability. It does not mention pagination or sorting, but those are less critical given the safe, 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 a single sentence that is dense with information: it names the resource, the type of records, and the specific data fields. It is front-loaded with the resource name and immediately conveys the purpose. There is no wordiness or 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?
Given the tool has an output schema (which presumably lists the response fields), the description doesn't need to detail return format. The description covers the essence: what the ledger contains and what fields are included. With annotations declaring it read-only and idempotent, and schema covering the parameters, the description is complete for correct invocation.
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%: both parameters (limit and query) have descriptions in the schema. The description does not add additional semantics beyond what's in the schema, but the schema already documents the parameters well, including default for limit and the filter fields. The baseline of 3 is appropriate because the schema carries the load.
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 resource (Revenue AI Report Reversal Ledger) and the specific data fields returned (vendor, function, seat, dates, cost, reason, source). It distinguishes itself from sibling list tools by naming the exact ledger, making it clear this is a specialized list, not a generic catalog.
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 implies when to use this tool: when you need reversal ledger records with specific details. It does not explicitly name alternatives or exclusions, but the specificity of the resource and fields makes the use case obvious. Given the sibling tools are generic getters/listers for other resources, the guidance is clear enough without explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse The Revenue AI Report skill library: repeatable AI jobs for revenue teams, each with a ready prompt, a process, decision rules, and limitations. Filter by role, task, or level.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Filter by the role the skill is written for. | |
| task | No | Filter by the job the skill finishes. | |
| level | No | Filter by difficulty. | |
| limit | No | ||
| query | No | Optional keyword filter on name and outcome. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| skills | Yes | |
| returned | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context about what skills contain (prompt, process, decision rules, limitations) but does not disclose additional operational behavior such as pagination, result ordering, or whether partial matches are returned. It does not contradict 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the purpose, and uses no filler. Every sentence contributes either the scope of the library or the available filtering behavior.
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 annotations, output schema, and relatively simple optional-filter design, the description is largely complete: it defines the domain and the main filter choices. Minor gaps remain around the meaning of limit and when to use get_skill for more detail, but these are not critical for correct invocation.
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 80%, and the description only restates the role/task/level filters already documented in the schema. It adds no new meaning for the limit parameter or the query parameter, so the description provides limited additional value beyond the structured 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 clearly identifies a specific resource (the Revenue AI Report skill library) and a specific action (browse/filter), plus the filter dimensions role, task, and level. It does not explicitly differentiate from sibling list tools, but the resource type 'skills' is distinct enough to make the 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?
Usage is implied by the verb 'Browse' and the filtering language, so an agent can infer this is for discovering skills. However, there is no explicit guidance about when to prefer this over related tools like get_skill, list_prompts, or search_site, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Define a revenue AI term using The Revenue AI Report glossary and plain-language dictionary. Covers Report frameworks, pillars, and measures plus general AI and go-to-market vocabulary.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | The word or phrase to define, e.g. 'proof gap' or 'RAG'. | |
| limit | No | Default 8. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| results | Yes | |
| glossaryTerms | Yes | |
| dictionaryTerms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's main added value is specifying the source and scope of definitions. It does not disclose how 'limit' affects results or what happens for unknown terms, but for a simple read-only lookup with an output schema this is not a critical gap.
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 action and object; the second sentence earns its place by clarifying scope. No filler and no repetition of schema details.
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 lookup with a required term, strong annotations, and an output schema, the description is nearly complete. The only real gap is the lack of explicit sibling routing, which is minor for a tool whose name and description already identify its distinct resource.
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 the baseline is 3. The description contextualizes the vocabulary domain, helping an agent choose a valid 'term', but it adds nothing about the 'limit' parameter beyond the schema's 'Default 8'.
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?
States a specific action ('Define') and a specific resource (The Revenue AI Report glossary and plain-language dictionary), and clarifies the vocabulary coverage. It does not explicitly contrast itself with sibling get_* and search_* tools, but the glossary/dictionary target is enough to make the intended purpose clear.
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 coverage note ('frameworks, pillars, measures... AI and go-to-market vocabulary') implies when the tool is relevant for terminology lookups. However, there is no explicit guidance on when to use this instead of search_site, get_framework, or get_publication, and no stated exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across The Revenue AI Report articles (titles, summaries, body text, keywords and FAQs). Returns matching articles with a short excerpt.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of matches to return. | |
| query | Yes | Search terms, e.g. 'AI pilot kill criteria'. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the detail that results include a short excerpt, which is useful for setting output expectations, and it implicitly confirms the closed-world scope (openWorldHint=false) by specifying the exact corpus. This adds some context but does not go far beyond what annotations and the schema imply.
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 with zero wasted words. The primary action and scope are front-loaded, and the excerpt detail is placed naturally. Every sentence earns its place, making it highly 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?
The tool is a straightforward search operation with an output schema available (not shown here). The description covers what is searched, the result format, and the scope. It does not mention sorting, pagination, or other edge-case behaviors, but given the low complexity and the presence of annotations and output schema, the description is sufficiently complete for an agent to invoke it correctly. A note about broader search alternatives would improve completeness but is not essential.
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 both parameters are already well-documented in the schema. The description adds value by explaining that the query performs full-text search across multiple fields, which gives semantic meaning to the 'query' parameter, but it does not provide additional parameter-specific syntax or constraints beyond the schema. This aligns with the baseline 3 for high schema 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 the verb 'search' with a specific resource ('The Revenue AI Report articles') and enumerates the fields searched (titles, summaries, body text, keywords, FAQs). It also mentions the return of excerpts, which distinguishes it from sibling tools like search_site and search_tools that likely have broader or different scopes.
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 clear context for when to use the tool: when searching across the specified article corpus. However, it does not explicitly mention alternatives or exclusions, such as 'for broader site search use search_site.' The scope is well-defined, so an agent can infer the appropriate context, but explicit routing to siblings would elevate this to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search every public resource on The Revenue AI Report in one call: articles, research themes, frameworks, methodology, skills, prompts, playbooks, datasets, archive issues, the reversal ledger, the AI tool library, and glossary and dictionary definitions. Filters: kind (resource type), category (article or issue pillar, playbook or prompt team, skill task, tool or ledger category, case insensitive), tags with tag_match ('all' requires every tag, 'any' requires one). Paging: limit (page size, default 12, max 40) with either offset or the next_cursor returned by the previous call. Results are ranked and stable for the same query and filters. Returns ranked matches with live URL, kind, category, tags and an excerpt, plus totalMatches, countsByKind, availableFilters for discovery, and nextCursor/hasMore for paging. Examples: {"query":"forecast accuracy"} | {"query":"pipeline hygiene","kind":"Playbook","category":"revops","tags":["L3"]} | {"query":"AI SDR","tags":["L2","sales"],"tag_match":"any"} | {"query":"AI SDR","limit":10,"offset":10} | {"query":"AI SDR","limit":10,"cursor":""} Use this first when you do not know which resource type answers the question.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Restrict results to one resource type, e.g. 'Playbook' or 'Skill'. | |
| tags | No | Tags to filter on. Tags include playbook tags, maturity levels (L1 to L6), skill roles and levels, prompt teams, and tool functions. Example: ['L3','sales']. | |
| limit | No | Page size. Default 12, max 40. | |
| query | Yes | What the user is looking for, e.g. 'AI SDR pilot kill criteria'. | |
| cursor | No | Opaque `next_cursor` from the previous call. Fetches the following page with the same query and filters. | |
| offset | No | How many ranked matches to skip before this page. Default 0. Ignored when `cursor` is given. | |
| category | No | Restrict to one category: article/issue pillar, playbook or prompt team, skill task, tool or ledger category. Case insensitive. Example: 'revops'. | |
| tag_match | No | How to apply `tags`. 'all' (default) keeps items carrying every tag. 'any' keeps items carrying at least one. |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| query | Yes | |
| offset | Yes | |
| filters | Yes | |
| hasMore | Yes | |
| results | Yes | |
| returned | Yes | |
| nextCursor | Yes | |
| nextOffset | Yes | |
| countsByKind | Yes | |
| totalMatches | Yes | |
| availableFilters | Yes | |
| indexedDocuments | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds valuable behavioral details: results are ranked and stable for the same query and filters, pagination uses cursor or offset, and it explains the exact output shape (matches, totalMatches, countsByKind, availableFilters, nextCursor/hasMore). This goes well 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but highly structured: it opens with the purpose and resource list, then covers filters, paging, output, examples, and a usage hint. It front-loads the core scope and is organized clearly, avoiding fluff. For a tool with 8 parameters, this level of detail is justified, though it could be slightly tightened.
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 complexity, the description covers all aspects an agent needs: what it searches, how to filter, how to page, what results look like, and when to use it. The output schema is also present, but the description independently explains the returned fields. It is complete for a read-only search 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%, so the schema already documents every parameter. The description adds meaning through concrete JSON examples that illustrate filter combinations, tag_match semantics, and paging usage, which helps agents construct valid calls more accurately than the schema alone. It does not fully compensate for a coverage gap (none exists), but it enriches understanding, so a 4 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 states a specific action ('Search every public resource ... in one call') and enumerates all resource types it covers, distinguishing it from sibling tools like get_playbook or search_tools. It also clarifies it is a cross-resource search, so an agent can immediately tell it apart from more targeted tools.
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 says 'Use this first when you do not know which resource type answers the question', giving a clear directive for when to invoke this tool over alternatives. While it doesn't name specific siblings, the instruction is unambiguous and sufficient for routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search The Revenue AI Report AI tool library: go-to-market and revenue AI vendors with category, revenue functions, use cases, adoption effort level, and vendor claims. Ranking runs on name, description, best-for, and use cases; vendor keywords only count on an exact whole-tag match, so a generic word does not pull in unrelated vendors. Filter with category, revenueFunction, maturity (adoption effort 1 to 5), or tag. Every response returns availableFilters with the full category and revenue-function lists plus the most common vendor tags, so you can re-run a narrowed query without guessing the taxonomy. Vendor claims are the vendor's own, not Report benchmarks.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Exact vendor keyword, for example 'forecasting'. See availableFilters.topTags. | |
| limit | No | Default 25. | |
| query | No | Keyword matched on name, description, best-for, and use cases, ranked by relevance. | |
| category | No | Exact tool category, for example 'Productivity & Automation'. See availableFilters.categories. | |
| maturity | No | Adoption effort level, 1 (one seat, no workflow change) to 5 (agent runs the work, human audits). | |
| revenueFunction | No | Exact revenue function, for example Sales, Marketing, Customer Success, Revenue Operations. See availableFilters.functions. |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| tools | Yes | |
| total | Yes | |
| matched | Yes | |
| returned | Yes | |
| adoptionLevels | Yes | |
| availableFilters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, and the description goes well beyond them by disclosing ranking inputs, exact-tag matching semantics, the guaranteed presence of availableFilters in every response, and the caveat that vendor claims are not Report benchmarks. 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?
The description is moderately long but every sentence contributes a distinct fact: purpose, ranking rule, filter options, availableFilters response behavior, and vendor-claims disclaimer. It is front-loaded with the purpose and does not waste words on fluff.
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 has 6 optional parameters, an output schema, and rich annotations, the description covers all essential operational semantics: what is searched, how ranking works, filter usage, how to discover valid filter values, and data provenance caveats. Nothing an agent needs to invoke it correctly 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 description coverage is 100%, so the baseline is 3. The description mostly restates what the schema already says about query matching, category/revenueFunction/tag, and maturity scale. It adds a useful note about exact tag matching and points to availableFilters for valid values, but this is only marginal added meaning beyond 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 clearly states the verb 'Search' and the specific resource: 'The Revenue AI Report AI tool library: go-to-market and revenue AI vendors...' It is scoped enough to be distinguished from sibling tools like search_publications or search_site, and the title reinforces the same purpose.
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 actionable usage guidance: it explains the ranking behavior, the exact whole-tag matching rule for vendor keywords, and how to use filters. It also tells users to re-run with availableFilters to refine queries. It does not explicitly state when not to use it or name alternatives, but the context is clear.
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.
get_dataset1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "dataset": {
+ "additionalProperties": {},
+ "properties": {
+ "answer": {
+ "type": "string"
+ },
+ "downloadUrl": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "faqs": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "a": {
+ "type": "string"
+ },
+ "q": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "q",
+ "a"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "h1": {
+ "type": "string"
+ },
+ "includes": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "notes": {
+ "type": "string"
+ },
+ "schema": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "description"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "h1",
+ "answer",
+ "includes",
+ "schema",
+ "notes",
+ "faqs",
+ "url",
+ "downloadUrl"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "dataset"
+ ],
+ "type": "object"
+}get_framework1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "framework": {
+ "additionalProperties": {},
+ "properties": {
+ "slug": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "url"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "framework"
+ ],
+ "type": "object"
+}get_playbook1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "playbook": {
+ "additionalProperties": {},
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "kpis": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "maturity": {
+ "type": "number"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "steps": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "detail": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "tool",
+ "detail"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "title",
+ "summary",
+ "category",
+ "maturity",
+ "tags",
+ "steps",
+ "kpis",
+ "url"
+ ],
+ "type": "object"
+ },
+ "relatedSkills": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "skillFileUrl": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "url",
+ "skillFileUrl"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "playbook",
+ "relatedSkills"
+ ],
+ "type": "object"
+}get_prompt1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "prompt": {
+ "additionalProperties": {},
+ "properties": {
+ "body": {
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "teams": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "summary",
+ "category",
+ "teams",
+ "body",
+ "url"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "prompt"
+ ],
+ "type": "object"
+}get_publication1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "article": {
+ "additionalProperties": {},
+ "properties": {
+ "author": {
+ "type": "string"
+ },
+ "body": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "date": {
+ "type": "string"
+ },
+ "faqs": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "a": {
+ "type": "string"
+ },
+ "q": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "q",
+ "a"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "pillar": {
+ "type": "string"
+ },
+ "readingTime": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "title",
+ "summary",
+ "pillar",
+ "date",
+ "author",
+ "readingTime",
+ "keywords",
+ "body",
+ "faqs",
+ "url"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "article"
+ ],
+ "type": "object"
+}get_publication_info1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "articleCount": {
+ "type": "number"
+ },
+ "audience": {
+ "type": "string"
+ },
+ "cadence": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "mission": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "pillars": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sponsorship": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "url",
+ "mission",
+ "description",
+ "audience",
+ "cadence",
+ "pillars",
+ "sponsorship",
+ "articleCount"
+ ],
+ "type": "object"
+}get_research1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "theme": {
+ "additionalProperties": {},
+ "properties": {
+ "charts": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "data": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "label",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "headline": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "source": {},
+ "sub": {
+ "type": "string"
+ },
+ "unit": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "headline",
+ "sub",
+ "unit",
+ "data",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "dek": {
+ "type": "string"
+ },
+ "intro": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "number": {
+ "type": "number"
+ },
+ "shortAnswer": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "sources": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "detail": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "detail",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "takeaways": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "unconfirmed": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "number",
+ "title",
+ "dek",
+ "shortAnswer",
+ "intro",
+ "charts",
+ "takeaways",
+ "sources",
+ "unconfirmed",
+ "url"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "theme"
+ ],
+ "type": "object"
+}get_resource1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "matches": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "kind": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "title",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "path": {
+ "type": "string"
+ },
+ "resource": {
+ "additionalProperties": {},
+ "properties": {
+ "kind": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "title",
+ "path",
+ "url",
+ "text"
+ ],
+ "type": "object"
+ }
+ },
+ "type": "object"
+}get_skill1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "relatedPlaybooks": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "title",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "relatedTools": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "skill": {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "skillFileUrl": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "url",
+ "skillFileUrl"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "skill",
+ "relatedPlaybooks",
+ "relatedTools"
+ ],
+ "type": "object"
+}get_tool1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "adoption": {
+ "additionalProperties": {},
+ "properties": {
+ "level": {
+ "type": "number"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "rationale": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "level",
+ "meaning",
+ "rationale"
+ ],
+ "type": "object"
+ },
+ "buyChecks": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "corporateStatus": {},
+ "evidence": {
+ "additionalProperties": {},
+ "properties": {
+ "caseStudies": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "customer": {
+ "type": "string"
+ },
+ "outcome": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "customer",
+ "outcome",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "claimAudits": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "claim": {
+ "type": "string"
+ },
+ "counter": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "claim",
+ "counter",
+ "source",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "fieldNote": {},
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "caseStudies",
+ "claimAudits",
+ "fieldNote"
+ ],
+ "type": "object"
+ },
+ "faqs": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "a": {
+ "type": "string"
+ },
+ "q": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "q",
+ "a"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "placement": {
+ "additionalProperties": {},
+ "properties": {
+ "oar": {
+ "type": "string"
+ },
+ "seat": {
+ "type": "string"
+ },
+ "stage": {
+ "type": "string"
+ },
+ "teams": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "stage",
+ "oar",
+ "seat",
+ "teams"
+ ],
+ "type": "object"
+ },
+ "relatedSkills": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "skillFileUrl": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "url",
+ "skillFileUrl"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "reversalLedger": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "company": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "company",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "tool": {
+ "additionalProperties": {},
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "functions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "maturity": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "website": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "category",
+ "description",
+ "functions",
+ "maturity",
+ "website",
+ "url"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "tool",
+ "placement",
+ "adoption",
+ "evidence",
+ "corporateStatus",
+ "reversalLedger",
+ "buyChecks",
+ "relatedSkills",
+ "faqs"
+ ],
+ "type": "object"
+}list_datasets1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "bundleUrl": {
+ "type": "string"
+ },
+ "datasets": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "downloadUrl": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "gated": {
+ "type": "boolean"
+ },
+ "live": {
+ "type": "boolean"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "title",
+ "summary",
+ "gated",
+ "url",
+ "downloadUrl"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "datePublished": {
+ "type": "string"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "datePublished",
+ "bundleUrl",
+ "datasets"
+ ],
+ "type": "object"
+}list_frameworks1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "frameworks": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "type",
+ "summary",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "seats": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "decision": {
+ "type": "string"
+ },
+ "failure": {
+ "type": "string"
+ },
+ "n": {
+ "type": "number"
+ },
+ "owns": {
+ "type": "string"
+ },
+ "role": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "n",
+ "role",
+ "owns",
+ "decision",
+ "failure"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "frameworks",
+ "seats"
+ ],
+ "type": "object"
+}list_playbooks1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "matched": {
+ "type": "number"
+ },
+ "playbooks": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "maturity": {
+ "type": "number"
+ },
+ "maturityLabel": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "steps": {
+ "type": "number"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "team": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "title",
+ "summary",
+ "team",
+ "maturity",
+ "maturityLabel",
+ "steps",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "returned": {
+ "type": "number"
+ },
+ "teams": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "matched",
+ "returned",
+ "teams",
+ "playbooks"
+ ],
+ "type": "object"
+}list_prompts1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "matched": {
+ "type": "number"
+ },
+ "prompts": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "teams": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "summary",
+ "category",
+ "teams",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "returned": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "matched",
+ "returned",
+ "prompts"
+ ],
+ "type": "object"
+}list_publications1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "items": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "date": {
+ "type": "string"
+ },
+ "pillar": {
+ "type": "string"
+ },
+ "readingTime": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "title",
+ "summary",
+ "pillar",
+ "date",
+ "readingTime",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "items"
+ ],
+ "type": "object"
+}list_research1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "researchRules": {},
+ "returned": {
+ "type": "number"
+ },
+ "themes": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "dek": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "sourceCount": {
+ "type": "number"
+ },
+ "takeaways": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "number",
+ "title",
+ "dek",
+ "takeaways",
+ "sourceCount",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "returned",
+ "themes",
+ "researchRules"
+ ],
+ "type": "object"
+}list_resources1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "resources": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "categories": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "count": {
+ "type": "number"
+ },
+ "hubUrl": {
+ "type": "string"
+ },
+ "kind": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "tools": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "count",
+ "hubUrl",
+ "tools",
+ "categories",
+ "tags"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "totalIndexed": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "totalIndexed",
+ "resources"
+ ],
+ "type": "object"
+}list_reversals1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "csvUrl": {
+ "type": "string"
+ },
+ "records": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "company": {
+ "type": "string"
+ },
+ "cost": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "deployed": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "functionArea": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "outcome": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "reversed": {
+ "type": "string"
+ },
+ "seat": {
+ "type": "string"
+ },
+ "sourceName": {
+ "type": "string"
+ },
+ "sourceUrl": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "url": {
+ "type": "string"
+ },
+ "vendor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "company",
+ "vendor",
+ "functionArea",
+ "seat",
+ "outcome",
+ "deployed",
+ "reversed",
+ "cost",
+ "reason",
+ "sourceName",
+ "sourceUrl",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "returned": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "returned",
+ "records",
+ "csvUrl"
+ ],
+ "type": "object"
+}list_skills1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "returned": {
+ "type": "number"
+ },
+ "skills": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "level": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "outcome": {
+ "type": "string"
+ },
+ "roles": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "setupTime": {
+ "type": "string"
+ },
+ "skillFileUrl": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "task": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "outcome",
+ "roles",
+ "task",
+ "level",
+ "setupTime",
+ "url",
+ "skillFileUrl"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "returned",
+ "skills"
+ ],
+ "type": "object"
+}lookup_term1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "dictionaryTerms": {
+ "type": "number"
+ },
+ "glossaryTerms": {
+ "type": "number"
+ },
+ "query": {
+ "type": "string"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "canonicalUrl": {
+ "type": "string"
+ },
+ "definition": {
+ "type": "string"
+ },
+ "group": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "source": {
+ "type": "string"
+ },
+ "term": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "term",
+ "definition",
+ "source",
+ "url",
+ "canonicalUrl"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "query",
+ "results",
+ "glossaryTerms",
+ "dictionaryTerms"
+ ],
+ "type": "object"
+}search_publications1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "results": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "date": {
+ "type": "string"
+ },
+ "excerpt": {
+ "type": "string"
+ },
+ "pillar": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "title",
+ "pillar",
+ "date",
+ "excerpt",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}search_site1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "availableFilters": {
+ "additionalProperties": {},
+ "properties": {
+ "categories": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "categories",
+ "tags"
+ ],
+ "type": "object"
+ },
+ "countsByKind": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "filters": {
+ "additionalProperties": {},
+ "properties": {
+ "category": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "kind": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "tagMatch": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "kind",
+ "category",
+ "tags",
+ "tagMatch"
+ ],
+ "type": "object"
+ },
+ "hasMore": {
+ "type": "boolean"
+ },
+ "indexedDocuments": {
+ "type": "number"
+ },
+ "limit": {
+ "type": "number"
+ },
+ "nextCursor": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "nextOffset": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "offset": {
+ "type": "number"
+ },
+ "query": {
+ "type": "string"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "category": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "excerpt": {
+ "type": "string"
+ },
+ "kind": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "title",
+ "path",
+ "url",
+ "category",
+ "tags",
+ "excerpt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "returned": {
+ "type": "number"
+ },
+ "totalMatches": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "query",
+ "filters",
+ "totalMatches",
+ "returned",
+ "offset",
+ "limit",
+ "hasMore",
+ "nextOffset",
+ "nextCursor",
+ "countsByKind",
+ "results",
+ "availableFilters",
+ "indexedDocuments"
+ ],
+ "type": "object"
+}search_tools1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "adoptionLevels": {},
+ "availableFilters": {
+ "additionalProperties": {},
+ "properties": {
+ "categories": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "functions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "maturity": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "topTags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "categories",
+ "functions",
+ "maturity",
+ "topTags"
+ ],
+ "type": "object"
+ },
+ "matched": {
+ "type": "number"
+ },
+ "note": {
+ "type": "string"
+ },
+ "returned": {
+ "type": "number"
+ },
+ "tools": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "functions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "maturity": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "website": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "category",
+ "description",
+ "functions",
+ "maturity",
+ "website",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "matched",
+ "returned",
+ "tools",
+ "adoptionLevels",
+ "availableFilters",
+ "note"
+ ],
+ "type": "object"
+}get_datasetget_frameworkget_playbookget_promptget_publicationget_publication_infoget_researchget_resourceget_skillget_toollist_datasetslist_frameworkslist_playbookslist_promptslist_publicationslist_researchlist_resourceslist_reversalslist_skillslookup_termsearch_publicationssearch_sitesearch_toolsAutonomous AI sales: agents, signal-based prospecting, outreach, CRM — 149 tools.
Strategist, ghostwriter, scheduler and analyst in one, inside your AI. LinkedIn, X, Substack.
AI-native GTM OS for B2B SaaS — account health, pipeline, renewals, territories, and benchmarks.
15 AI revenue intelligence tools for Salesforce — pipeline, deals, coaching, competitors.
Add one secure layer between your agents and this server.
