A connector providing AI assistants searchable access to climate-aligned contract clauses, glossary terms, and practical guides from The Chancery Lane Project's curated knowledge graph.
Scored across 4 tools
Each tool has a clearly distinct purpose: entity_lookup for exact entity matching, search for semantic/full-text search, taxonomy_content for filtered browsing, and taxonomy_facets for discovering filter options. There is no overlap or ambiguity.
All tool names follow a consistent snake_case pattern with descriptive, domain-specific names (entity_lookup, search, taxonomy_content, taxonomy_facets). The naming is predictable and self-explanatory.
With 4 tools, the set is well-scoped for searching and browsing a legal content knowledge graph. Each tool serves a clear, necessary function without redundancy, and the count feels appropriate for the domain.
The tools cover key discovery use cases: exact lookup, free-text search, faceted browsing, and facet exploration. A minor gap is the lack of tools for creating, updating, or deleting content, but that aligns with a read-only knowledge graph server, so completeness is high.
Find TCLP content nodes (clauses, glossary terms) associated with a named concept.
Unlike `search`, this performs a deterministic name match against Entity nodes in
the knowledge graph rather than a relevance-ranked semantic search. Use it when
you have a specific term or concept (e.g. "scope 3 emissions", "net zero") and
want to retrieve every clause or glossary entry that explicitly references it.
Args:
name: The entity or concept name to look up (exact match, case-insensitive).
limit: Maximum number of results to return (1–50).
include_full_text: Include each hit's full body text (Markdown). Off by
default — bodies are large; request only when you need the content,
and prefer a small `limit` when you do.
Returns:
JSON with "meta" and "results" where each hit includes the source content
node and the entity names that matched.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| limit | No | ||
| include_full_text | No |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint=true, destructiveHint=false) by describing a lookup operation. It adds context about deterministic name matching (case-insensitive, exact match) and warns that `include_full_text` bodies are large, which goes beyond annotations. However, it doesn't mention any potential performance implications of large result sets or AI model context limitations, keeping it from a 5.
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 extremely concise and well-structured: a one-line purpose statement, a clear paragraph distinguishing from `search` with usage advice, a brief 'Args' section documenting parameters, and a concise 'Returns' summary. Every sentence adds value with no 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 3 simple parameters (one required), annotations declaring it safe and open-world, and an output schema providing return structure, the description is complete. It covers the purpose, usage, parameter details, and return format comprehensively. No gaps are evident for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully carries parameter documentation. It explains `name` is an 'exact match, case-insensitive' search term, `limit` is a 'Maximum number of results' (1–50), and `include_full_text` governs including full body text (Markdown) with usage warnings. This adds significant value beyond the schema's bare types and defaults, but a 5 would require even more detail (e.g., default value re-stated for `name`).
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 finds 'TCLP content nodes (clauses, glossary terms) associated with a named concept', using specific verbs ('Find') and resources ('Entity nodes in the knowledge graph'). It distinguishes itself from the sibling 'search' by highlighting deterministic vs. semantic matching, though it doesn't explicitly contrast with 'taxonomy_content' or 'taxonomy_facets'.
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 contrasts with 'search' ('Unlike `search`...'), explains when to use this tool ('when you have a specific term... and want to retrieve every clause or glossary entry that explicitly references it'), and provides detailed guidance for the `include_full_text` parameter ('request only when you need the content, and prefer a small `limit` when you do'). This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the TCLP knowledge graph using fusion search (semantic + BM25).
Args:
query: Free-text search query (max 1000 characters).
node_type: Content scope — "tclp" (clauses, glossary terms, guides),
"lrsf" (laws, regulations, standards, frameworks), or "all".
limit: Maximum number of results to return (1–50).
rerank: Whether to apply RRF reranking when combining graph and text results.
include_full_text: Include each hit's full body text (Markdown). Off by
default — bodies are large; request only when you need the content,
and prefer a small `limit` when you do.
Returns:
JSON with "meta" (totals, timing) and "results" (ranked hits with title,
url, content_type, scores, and optionally relationships and full_text).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| rerank | No | ||
| node_type | No | all | |
| include_full_text | No |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds valuable behavioral context: mentions fusion search, RRF reranking, and warns that bodies are large, which goes beyond annotation 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?
Description is well-structured with Args section and Returns section, each parameter documented succinctly. Every sentence adds value, and the warning about body size is concise yet crucial. 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?
Given 5 parameters, 0% schema coverage, and available output schema, the description fully explains all parameters, their defaults, and usage nuances. The return format is described (JSON with meta and results), and the output schema can handle details. Completely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It does: defines query as free-text (max 1000 chars), node_type as content scope with specific vocab, limit as 1–50, rerank as RRF switching, and include_full_text with a usage warning. This adds significant 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 tool searches the TCLP knowledge graph using fusion search (semantic + BM25), which is a specific verb+resource combination. It distinguishes from siblings like entity_lookup and taxonomy queries.
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 on when to use this tool (for full-text search) and includes a practical note on include_full_text (request only when needed, prefer small limit). However, it does not explicitly state when NOT to use it or point to alternatives for specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List TCLP content (clauses, guides) filtered by taxonomy facet=value.
Multi-facet filters are combined with AND. Call `taxonomy_facets` first
to learn which facet names and slugs exist; using a name not in that
list returns a 400.
Args:
filters: Mapping of facet name to value slug, e.g.
`{"sector": "real-estate", "practice_area": "commercial"}`.
Each facet may appear at most once.
scope: `clause`, `guide`, or `all` (default).
limit: Maximum results to return (1–100, default 25).
offset: Result offset for paging (default 0).
sort: `title`, `date_published_desc`, or `date_modified_desc`.
Returns:
JSON with "meta" (totals, scope, filters echoed back) and "results"
(each hit has `id`, `url`, `title`, `content_type`, dates, and a
`facets` map of all taxonomy arrays on the node).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | title | |
| limit | No | ||
| scope | No | all | |
| offset | No | ||
| filters | Yes |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only (readOnlyHint true) and non-destructive (destructiveHint false). The description reinforces this with a listing action and adds key behavioral details: multi-facet AND logic, 400 error for invalid facets, and the constraint that each facet appears at most once. 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 well-structured with a brief summary in the first sentence, followed by usage guidance and a clear parameter listing. It is relatively concise but could be slightly trimmed; however, the completeness justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (1 required), no enums, nested object input, and an output schema, the description fully covers parameter semantics, filtering behavior, error cases, and return format. The output schema is present, so the description of return values is sufficient (meta and results with key fields). No gaps remain.
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 0% schema description coverage, the description must fully compensate, and it does. It explains `filters` as a mapping of facet name to value slug, gives an example, and notes the 'at most once' constraint. It defines valid values for `scope` (clause/guide/all) and `sort` (title, date_published_desc, date_modified_desc). It also provides default values and ranges for `limit` (1-100) and `offset`.
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 TCLP content filtered by taxonomy facet=value. It specifies the resource (TCLP content like clauses and guides), the action (list), and the filtering mechanism. This distinguishes it from siblings like `taxonomy_facets` (which returns available facets) and `search` (general search).
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 instructs to call `taxonomy_facets` first to learn valid facet names, and warns that using an invalid name returns a 400 error. It also explains the AND combination of multi-facet filters. This provides clear when-to-use and prerequisite guidance, differentiating from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List taxonomy facets and their value slugs across TCLP content.
Facets are taxonomy categories like `sector`, `practice_area`,
`application`, and `jurisdiction`. Each facet returns the list of slugs
that actually appear on the graph, with counts. Use this to discover
the vocabulary, then call `taxonomy_content` with chosen slugs.
Args:
scope: Which labels to include — `clause` (ClauseName only),
`guide` (Guide only), or `all` (both, the default).
Returns:
JSON with "meta" and "facets". Each facet has `name`, `applies_to`
(list of Neo4j labels carrying it), and `values` (list of
`{slug, count}`, sorted by count desc).
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | all |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| facets | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds significant behavioral context: facets return only slugs that actually appear on the graph, include counts, and are sorted by count descending. It also explains the scope parameter's effect on which labels are included. This goes well beyond the annotations, providing essential behavior details for an agent.
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 well-structured: it starts with the main purpose, then explains facets, gives usage guidance, and finally details the parameter and return value. It is informative but not overly verbose. Minor improvement could be made by trimming the explanation of facets (e.g., 'Facets are taxonomy categories...') to be more concise. Still, it is effective and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter, detailed annotations, and the presence of an output schema (though not provided), the description is remarkably complete. It explains the parameter constraints, the return structure (JSON with 'meta' and 'facets', each facet including name, applies_to, and values), and the sorting. The only minor omission is the content of 'meta', but it is not critical for the agent's use. The description fully equips the agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single optional parameter 'scope' with no description or enum constraints (schema description coverage 0%). The description fully compensates by enumerating the valid values: 'clause', 'guide', 'all', explaining what each means, and noting the default. This adds crucial meaning that the schema alone fails to provide, enabling correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List taxonomy facets and their value slugs across TCLP content.' It provides concrete examples of facets (sector, practice_area, etc.) and mentions counts. It also distinguishes from the sibling tool taxonomy_content by advising to use this first and then call taxonomy_content with chosen slugs. The verb 'list' and resource 'taxonomy facets and value slugs' are specific and 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?
The description explicitly explains when to use this tool: 'Use this to discover the vocabulary, then call taxonomy_content with chosen slugs.' This directly tells the agent to use taxonomy_facets first to obtain valid slugs before using taxonomy_content. It does not mention entity_lookup or search, but the guidance is clear and sufficient for selecting the correct tool in a workflow.
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.
entity_lookup1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "_EntityHit": {
+ "properties": {
+ "content_type": {
+ "title": "Content Type",
+ "type": "string"
+ },
+ "entity_matches": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Entity Matches"
+ },
+ "full_text": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Full Text"
+ },
+ "id": {
+ "title": "Id",
+ "type": "string"
+ },
+ "ranks": {
+ "$ref": "#/$defs/_SearchRanks"
+ },
+ "relationships": {
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/_Relationship"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Relationships"
+ },
+ "scores": {
+ "$ref": "#/$defs/_SearchScores"
+ },
+ "title": {
+ "title": "Title",
+ "type": "string"
+ },
+ "url": {
+ "title": "Url",
+ "type": "string"
+ }
+ },
+ "title": "_EntityHit",
+ "type": "object"
+ },
+ "_Relationship": {
+ "properties": {
+ "path_types": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Path Types",
+ "type": "array"
+ },
+ "target_id": {
+ "title": "Target Id",
+ "type": "string"
+ },
+ "target_label": {
+ "title": "Target Label",
+ "type": "string"
+ },
+ "target_name": {
+ "title": "Target Name",
+ "type": "string"
+ },
+ "target_url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Target Url"
+ }
+ },
+ "required": [
+ "path_types",
+ "target_id",
+ "target_label",
+ "target_name",
+ "target_url"
+ ],
+ "title": "_Relationship",
+ "type": "object"
+ },
+ "_SearchMeta": {
+ "properties": {
+ "degraded": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Degraded",
+ "type": "array"
+ },
+ "graph_total": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Graph Total"
+ },
+ "request_id": {
+ "title": "Request Id",
+ "type": "string"
+ },
+ "text_total": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Text Total"
+ },
+ "took_ms": {
+ "title": "Took Ms",
+ "type": "integer"
+ },
+ "total_available": {
+ "title": "Total Available",
+ "type": "integer"
+ }
+ },
+ "title": "_SearchMeta",
+ "type": "object"
+ },
+ "_SearchRanks": {
+ "properties": {
+ "bm25": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Bm25"
+ },
+ "combined": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Combined"
+ },
+ "graph": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Graph"
+ }
+ },
+ "title": "_SearchRanks",
+ "type": "object"
+ },
+ "_SearchScores": {
+ "properties": {
+ "bm25": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Bm25"
+ },
+ "graph": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Graph"
+ }
+ },
+ "title": "_SearchScores",
+ "type": "object"
+ }
+ },
+ "properties": {
+ "meta": {
+ "$ref": "#/$defs/_SearchMeta"
+ },
+ "results": {
+ "items": {
+ "$ref": "#/$defs/_EntityHit"
+ },
+ "title": "Results",
+ "type": "array"
+ }
+ },
+ "required": [
+ "meta",
+ "results"
+ ],
+ "title": "EntityLookupResult",
+ "type": "object"
+}search1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "_SearchHit": {
+ "properties": {
+ "content_type": {
+ "title": "Content Type",
+ "type": "string"
+ },
+ "entity_matches": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Entity Matches"
+ },
+ "full_text": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Full Text"
+ },
+ "id": {
+ "title": "Id",
+ "type": "string"
+ },
+ "ranks": {
+ "$ref": "#/$defs/_SearchRanks"
+ },
+ "relationships_text": {
+ "title": "Relationships Text",
+ "type": "string"
+ },
+ "scores": {
+ "$ref": "#/$defs/_SearchScores"
+ },
+ "title": {
+ "title": "Title",
+ "type": "string"
+ },
+ "url": {
+ "title": "Url",
+ "type": "string"
+ }
+ },
+ "title": "_SearchHit",
+ "type": "object"
+ },
+ "_SearchMeta": {
+ "properties": {
+ "degraded": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Degraded",
+ "type": "array"
+ },
+ "graph_total": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Graph Total"
+ },
+ "request_id": {
+ "title": "Request Id",
+ "type": "string"
+ },
+ "text_total": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Text Total"
+ },
+ "took_ms": {
+ "title": "Took Ms",
+ "type": "integer"
+ },
+ "total_available": {
+ "title": "Total Available",
+ "type": "integer"
+ }
+ },
+ "title": "_SearchMeta",
+ "type": "object"
+ },
+ "_SearchRanks": {
+ "properties": {
+ "bm25": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Bm25"
+ },
+ "combined": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Combined"
+ },
+ "graph": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Graph"
+ }
+ },
+ "title": "_SearchRanks",
+ "type": "object"
+ },
+ "_SearchScores": {
+ "properties": {
+ "bm25": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Bm25"
+ },
+ "graph": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Graph"
+ }
+ },
+ "title": "_SearchScores",
+ "type": "object"
+ }
+ },
+ "properties": {
+ "meta": {
+ "$ref": "#/$defs/_SearchMeta"
+ },
+ "results": {
+ "items": {
+ "$ref": "#/$defs/_SearchHit"
+ },
+ "title": "Results",
+ "type": "array"
+ }
+ },
+ "required": [
+ "meta",
+ "results"
+ ],
+ "title": "SearchResult",
+ "type": "object"
+}taxonomy_content1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "_TaxonomyContentHit": {
+ "properties": {
+ "content_type": {
+ "title": "Content Type",
+ "type": "string"
+ },
+ "date_modified": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Date Modified"
+ },
+ "date_published": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Date Published"
+ },
+ "facets": {
+ "additionalProperties": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": "Facets",
+ "type": "object"
+ },
+ "id": {
+ "title": "Id",
+ "type": "string"
+ },
+ "title": {
+ "title": "Title",
+ "type": "string"
+ },
+ "url": {
+ "title": "Url",
+ "type": "string"
+ }
+ },
+ "title": "_TaxonomyContentHit",
+ "type": "object"
+ },
+ "_TaxonomyContentMeta": {
+ "properties": {
+ "filters": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "title": "Filters",
+ "type": "object"
+ },
+ "request_id": {
+ "title": "Request Id",
+ "type": "string"
+ },
+ "scope": {
+ "title": "Scope",
+ "type": "string"
+ },
+ "took_ms": {
+ "title": "Took Ms",
+ "type": "integer"
+ },
+ "total_available": {
+ "title": "Total Available",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total_available",
+ "took_ms",
+ "request_id",
+ "scope",
+ "filters"
+ ],
+ "title": "_TaxonomyContentMeta",
+ "type": "object"
+ }
+ },
+ "properties": {
+ "meta": {
+ "$ref": "#/$defs/_TaxonomyContentMeta"
+ },
+ "results": {
+ "items": {
+ "$ref": "#/$defs/_TaxonomyContentHit"
+ },
+ "title": "Results",
+ "type": "array"
+ }
+ },
+ "required": [
+ "meta",
+ "results"
+ ],
+ "title": "TaxonomyContentResult",
+ "type": "object"
+}taxonomy_facets1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "_TaxonomyFacet": {
+ "properties": {
+ "applies_to": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Applies To",
+ "type": "array"
+ },
+ "name": {
+ "title": "Name",
+ "type": "string"
+ },
+ "values": {
+ "items": {
+ "$ref": "#/$defs/_TaxonomyFacetValue"
+ },
+ "title": "Values",
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "applies_to",
+ "values"
+ ],
+ "title": "_TaxonomyFacet",
+ "type": "object"
+ },
+ "_TaxonomyFacetValue": {
+ "properties": {
+ "count": {
+ "title": "Count",
+ "type": "integer"
+ },
+ "slug": {
+ "title": "Slug",
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "count"
+ ],
+ "title": "_TaxonomyFacetValue",
+ "type": "object"
+ },
+ "_TaxonomyFacetsMeta": {
+ "properties": {
+ "request_id": {
+ "title": "Request Id",
+ "type": "string"
+ },
+ "took_ms": {
+ "title": "Took Ms",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "took_ms",
+ "request_id"
+ ],
+ "title": "_TaxonomyFacetsMeta",
+ "type": "object"
+ }
+ },
+ "properties": {
+ "facets": {
+ "items": {
+ "$ref": "#/$defs/_TaxonomyFacet"
+ },
+ "title": "Facets",
+ "type": "array"
+ },
+ "meta": {
+ "$ref": "#/$defs/_TaxonomyFacetsMeta"
+ }
+ },
+ "required": [
+ "meta",
+ "facets"
+ ],
+ "title": "TaxonomyFacetsResult",
+ "type": "object"
+}entity_lookupsearchtaxonomy_contenttaxonomy_facets
Add one secure layer between your agents and this server.