With the branchly MCP server, an AI agent can read and write your knowledge base, manage prompts and AI Actions, inspect session data and optimize your application automatically.
Create a new data source for the authenticated application. The 'settings' object must match the given 'type'. Returns the created data source. Creating a data source does not sync any content — use run_data_source to start a sync.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-readable display name of the data source (e.g. 'Company Website'). | |
| type | Yes | Must match the 'type' discriminator of the 'settings' object when both are provided. | |
| schedule | No | Cron expression (e.g. '0 3 * * *') or null to disable scheduled re-sync. | |
| settings | Yes | Type-specific config. Pass as an inline JSON object — do NOT serialize to a string. Must include a 'type' discriminator field: 'website_crawler', 'pdf_upload', 'open_api', 'helpspace', 'custom_webcrawler', or 'webhook'. | |
| integration_id | No | Integration UUID for connected data sources. Required for WordPress data sources. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as a mutation (readOnlyHint=false), and the description is consistent with that. Beyond the annotations, it adds non-obvious behavioral context: creation is decoupled from syncing, the created resource is returned, and settings must match the type discriminator. This is precisely the kind of side-effect semantics that structured annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: the purpose statement, the constraint plus return value, and the critical no-sync disclosure with the alternative tool. Information is front-loaded, and every sentence earns its place. Ideal size for a tool with this much schema complexity.
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 massive settings oneOf (7 variants), the output schema, and 100% schema coverage, the description need not enumerate settings variants — the schema handles that. It covers the create action, the settings/type coupling, the return value, and the sync follow-up. A brief hint about integration_id being required for WordPress sources would round it out, but the schema already documents that.
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 schema already documents name, type, schedule, settings, and integration_id, with the settings oneOf carrying extensive per-variant detail. The description reinforces the critical invariant ('settings' object must match the given 'type') but adds no syntax or format details beyond what the schema provides. Baseline 3 is correct 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?
States a specific verb ('Create'), resource ('data source'), and scope ('authenticated application'). It distinguishes itself from run_data_source by explicitly noting that creation does not sync content, and the resource name separates it from sibling create_node/create_prompt/create_tool. No ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names run_data_source as the alternative with the exact condition that selects it: 'Creating a data source does not sync any content — use run_data_source to start a sync.' This resolves the main usage ambiguity for a create-type tool. It doesn't enumerate every sibling (e.g., update_data_source for modifications), but the critical routing decision is fully covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new content node in the knowledge base. Label defaults to 'content'.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Locale-keyed body content (HTML) map, e.g. {"de": "<p>Inhalt</p>", "en": "<p>Content</p>"}. | |
| label | No | content | |
| title | Yes | Locale-keyed title map, e.g. {"de": "Titel", "en": "Title"}. | |
| source | No | Source URL for the node content. | |
| score_boost | No | Boost value for search ranking. Higher is better. Use null for no boost. | |
| custom_metadata | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply states it creates a node, which is already implied by readOnlyHint=false. It does not disclose what happens on success, whether a unique identifier is returned, how existing nodes are affected, or any other behavioral traits beyond the structured 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 very short and front-loaded with the core action. However, the label default sentence is redundant with the schema and does not fully earn its place, though it does not significantly bloat the description.
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 moderate-complexity create operation, the description plus the schema provides enough to invoke the tool, but it lacks any behavioral context or relationship to sibling tools. The output schema covers return values, so that gap is acceptable, but usage guidance 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 description only mentions that 'Label defaults to 'content'', which merely repeats the schema's default value. It adds no meaning about title, text, source, score_boost, or custom_metadata beyond what the schema already documents, and schema coverage is only 67%.
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 and resource: 'Create a new content node in the knowledge base.' It clearly distinguishes the operation from sibling tools like read_node, update_node, and list_nodes by stating 'new' and 'knowledge base'.
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 does not provide any guidance about when to use this tool versus alternatives like create_prompt or update_node. There is no mention of exclusions, prerequisites, or scenarios that would favor a different sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new prompt version for the authenticated application. The new prompt is automatically set as active and the previously active prompt of the same type and subtype is deactivated. Use this whenever you want to change prompt text.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Types of prompts in the system. | |
| prompt | Yes | ||
| subtype | No | 'routing_instructions' or 'output_instructions'. Returns all when omitted. | |
| interface_type | No | Interface scope of the prompt: 'chat', 'navigator', 'search', or 'api'. Required for 'chat' and 'search_answering' prompt types; omit for 'suggested_questions' and 'chat_evaluation'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no rich annotations beyond non-hints, the description carries the burden of disclosing side effects. It adds important behavior: the new prompt becomes active immediately and the previously active prompt of the same type/subtype is deactivated. This goes beyond the generic 'create' verb and gives an agent accurate expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry all essential information with no wasted words. The core action and its key behavioral consequence are front-loaded before the usage directive.
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 that an output schema exists and the schema documents most parameters, the description is complete for execution. It covers the primary behavioral consequence (activation/deactivation) and the intended use case. It could have named update_prompt as an explicit alternative or explained when a new version is not appropriate, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema already documents most parameters. The description reinforces the semantic relationship between type/subtype and the deactivation behavior, but does not add granular detail for the prompt value or interface_type beyond what the schema provides. This meets the baseline without exceeding it.
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: 'Create a new prompt version for the authenticated application.' It immediately differentiates the tool from siblings like update_prompt by explaining that creation produces a new version and automatically deactivates the prior active prompt. This is unambiguous and complete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use it: 'Use this whenever you want to change prompt text.' While it doesn't name the alternative update_prompt or explicitly say when not to use it, the guidance is clear and sufficient for most selection decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new tool (AI action) for the authenticated application. Tool names must be unique per application, snake_case, max 64 chars. 'tool_config' and 'function_arguments' must match the given 'tool_type'. Returns the created tool.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | snake_case tool name, max 64 characters. Used as the function name when the LLM calls the tool. | |
| agents | No | Optional list of agent types that may use this tool: 'chat_routing', 'chat_output', 'search_answer', 'form_answer', 'form_routing', 'follow_up_actions', 'suggested_questions'. | |
| tool_type | Yes | Type of the tool: 'knowledge_base', 'openAPI', 'node_lookup', 'send_email', 'form', 'contact_information', 'web_search', 'web_page_reader', 'weather', 'venus_knowledge_graph', 'regiondo', 'mcp_server', 'api', 'buttons', 'google_maps_link', 'google_maps_embed', or 'calendly'. | |
| description | Yes | Natural-language description of what the tool does and when the LLM should call it. | |
| tool_config | No | Function schema sent to the LLM. Pass as an inline JSON object — do NOT serialize to a string. Use 'FormAPISchema' for form tools or 'APIToolConfig' for API-calling tools. Pass null to clear. | |
| function_arguments | No | Fixed runtime arguments NOT collected from the LLM (e.g. recipient email, rerank flag, knowledge-base ID). Pass as an inline JSON object — do NOT serialize to a string. Must include an 'object' discriminator field matching the tool type. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so they provide minimal behavioral signal. The description clarifies that tool_config and function_arguments must match tool_type, and that names must be unique per application, which are useful behavioral notes. However, it does not disclose side effects beyond creation (e.g., whether creation is immediately active, any permission requirements), though it does state it returns the created tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact three-sentence block that leads with the primary action, then the most important constraints, then the return value. It does not enumerate every tool_type variant, which is left to the schema. A slight deduction because the key matching constraint between tool_config/function_arguments and tool_type is stated tersely without examples, but it is still 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 complex, with 6 parameters and deep nested schemas for tool_config and function_arguments. The description points to the matching constraint and return value, but does not explain the tool_type+tool_config+function_arguments combination rules in a way that would let an agent confidently construct a valid request without reading the schema closely. However, the schema itself is rich and the output schema exists, so the description delegates appropriately.
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 all parameters. The description adds cross-parameter semantics: 'tool_config' and 'function_arguments' must match 'tool_type', and in the schema's own tool_config description it adds the critical guidance 'Pass as an inline JSON object — do NOT serialize to a string.' The function_arguments description adds the 'object discriminator field' requirement. These are valuable beyond the raw 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 states a specific verb and resource: 'Create a new tool (AI action) for the authenticated application.' It also adds key constraints (unique name, snake_case, max 64 chars). Among siblings, create_tool is distinct from create_data_source, create_node, create_prompt, though the description does not explicitly differentiate from these; the 'tool (AI action)' parenthetical and mention of tool_config/function_arguments make the resource 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 description implies usage context (creating a tool for the app) but does not explicitly state when to use this tool versus alternatives like update_tool or list_tools. The uniqueness and naming constraints are helpful guidance for invoking it correctly, but there is no when/when-not guidance or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Time series of active sessions broken down by embed type (chat, chat_widget, navigator, search_interface, voice, api). Use this to understand which interfaces are driving usage.
| Name | Required | Description | Default |
|---|---|---|---|
| time_filter | No | Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive). | last_30_days |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description need not restate read-only behavior. It adds context about the time-series shape and the breakdown by embed type, but does not disclose other behavioral traits like aggregation interval, response size, or how missing embed values are handled.
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 filler; the core output and breakdown are stated first, followed by a direct usage rationale. 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?
With one optional, fully documented parameter, a read-only annotation, and an output schema, the description is nearly complete for correct invocation. It could be stronger by explicitly contrasting with get_active_sessions_over_time, but the embed-breakdown language already routes an agent reasonably well.
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, time_filter, is fully and clearly documented in the schema with presets, a custom-range pattern, defaults, and inclusivity semantics. With 100% schema description coverage, the tool description has no obligation to repeat parameter details, and it adds no extra meaning beyond what the schema provides.
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 resource and dimension: a time series of active sessions broken down by embed type, with the enum of embed types explicitly listed. It differentiates from sibling get_active_sessions_over_time by emphasizing the breakdown, though it does not explicitly name that sibling or state what the tool is not.
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?
'Use this to understand which interfaces are driving usage' gives clear and relevant context for when the tool is the right choice. It does not mention alternatives or exclusion cases, such as when total active sessions without a breakdown would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Time series of active sessions, bucketed by day or week (auto-chosen from the time window). Each row breaks the total down by interaction type (chat / search / navigation / form_submission / voice). Gaps are zero-filled, so the series is safe to plot directly. Use this to spot spikes, dips, or trends.
| Name | Required | Description | Default |
|---|---|---|---|
| embed_types | No | Restrict to sessions initiated through these embed type(s). Omit to include all embeds. | |
| time_filter | No | Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive). | last_30_days |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, and the description adds valuable behavioral details beyond that: bucketing is auto-chosen from the time window, gaps are zero-filled, and the result is safe to plot directly. This goes well beyond the readOnlyHint and helps an agent trust the output shape without hidden nulls or missing periods.
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. Each sentence adds distinct value: what the series is, how it is structured, and when to use it. The core meaning is front-loaded in the first sentence.
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?
Complemented by an output schema, read-only annotations, and fully documented optional parameters, the description covers what the time series contains, how bucketing works, how missing data is handled, and a clear use case. Nothing essential is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (embed_types and time_filter) are fully documented in the schema. The description does not need to repeat parameter details, though it adds some conceptual context about interaction types. Baseline 3 is appropriate since the schema carries the parameter explanation burden.
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 returns a time series of active sessions, bucketed by day or week and broken down by interaction type. It specifies the resource ('active sessions'), the action ('time series'), and the structure ('each row breaks the total down'), making it distinct from sibling tools like get_active_sessions_by_embed.
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 'Use this to spot spikes, dips, or trends,' giving an actionable use case. It does not explicitly mention alternatives, but the context is clear enough that an agent can infer when this tool is appropriate versus non-time-series analytics tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Distribution of chat answer types (e.g. 'answered', 'no_answer', 'tool_call', 'human_handoff'), ranked by occurrence count. Use this to monitor answer quality: a high 'no_answer' share signals content gaps; a high 'human_handoff' share signals where the bot is escalating.
| Name | Required | Description | Default |
|---|---|---|---|
| time_filter | No | Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive). | last_30_days |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds that results are ranked by occurrence count and gives interpretive context, but it does not reveal additional behavioral details such as aggregation windows, time-filter handling quirks, or any constraints beyond 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?
Two compact sentences front-load the core purpose and follow with decision-relevant interpretation. There is no filler, repetition of schema details, or unnecessary elaboration.
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 single fully documented optional parameter, the description supplies the only missing context: what the distribution means and how to interpret it for answer-quality monitoring. Everything needed to call the tool correctly is present.
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, time_filter, is fully documented by the schema through its enum, pattern, and default value, so schema coverage is 100%. The description contributes no parameter-specific guidance, which matches the baseline for fully schema-covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: a distribution of chat answer types such as 'answered', 'no_answer', 'tool_call', and 'human_handoff', ranked by occurrence count. It is semantically distinct from the sibling analytics tools, but it never uses an explicit verb like 'returns' or 'retrieves', nor does it name a sibling for comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete use case: monitor answer quality by watching 'no_answer' and 'human_handoff' shares. It tells the agent when this tool is useful, but it does not state when not to use it or explicitly mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full configuration of the authenticated application.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The 'Return' wording aligns with the readOnlyHint annotation, and 'full configuration' gives some scope context. However, the description adds little behavioral detail beyond what the annotations already convey, and it does not describe any special behavior or 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, well-structured sentence with no filler or redundancy. It front-loads the action and resource, making it easy for an agent to parse 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 that there are no parameters, an output schema exists, and the annotations declare read-only behavior, the description is sufficient for an agent to select and invoke the tool. No critical context 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 100% schema description coverage, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because no parameter information is needed.
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 ('Return') and a specific resource ('the full configuration of the authenticated application'). It is clearly distinct from all sibling tools, none of which target application configuration.
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 need the current application's full configuration—but it does not explicitly state alternatives or exclusions. There is no clear usage guidance beyond the resource name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sentiment distribution of chat answers as counts of 'positive', 'negative', and 'neutral'. Optionally restrict to specific answer types. Use this as a quick quality signal — a rising 'negative' share usually warrants drilling into individual sessions via read_sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| time_filter | No | Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive). | last_30_days |
| answer_types | No | Restrict to chat requests whose final answer matched one of these types. Omit to include all answer types. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint already tells the agent this is safe to call, and the schema/output schema cover the data shape. The description adds an interpretive behavioral cue ('a rising negative share usually warrants drilling') that is useful but doesn't disclose additional mechanics such as aggregation scope or latency; with annotations covering safety, this is adequate but not rich.
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-load the output shape, then state the optional filter and the business use case. There is no filler and every sentence contributes to selection or invocation.
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?
Together with the 100%-covered schema, output schema, and read-only annotation, the description is essentially complete for calling this tool. It would be slightly stronger if it explicitly distinguished itself from get_answer_type_distribution, but that is a minor gap given the clarity of 'sentiment' as opposed to 'answer type'.
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 parameters are already fully documented. The description only restates the optionality of answer_types ('Optionally restrict to specific answer types') and adds nothing about time_filter; baseline 3 is appropriate because the schema carries that burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning a sentiment distribution ('counts of positive, negative, neutral') over chat answers, so an agent knows what data to expect. It lacks an explicit verb like 'returns' and does not call out the similarly named sibling get_answer_type_distribution, but the sentiment-vs-type distinction is inferable from the description.
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 gives a concrete use case ('quick quality signal') and an explicit follow-up path ('drilling into individual sessions via read_sessions') when negative sentiment rises. It doesn't enumerate exclusions or compare with get_answer_type_distribution, but the guidance is actionable and specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Knowledge-base nodes most frequently cited in chat answers, ranked by citation count. Each row carries the node UUID (vertex_id), its title, optional source URL, and citation_count. Use this to understand which knowledge is actually load-bearing; pair with read_node(vertex_id) to inspect cited content.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of rows to return, ordered by count descending. | |
| embed_types | No | Restrict to sessions initiated through these embed type(s). Omit to include all embeds. | |
| time_filter | No | Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive). | last_30_days |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety, and the description adds row-shape details and ranking behavior. It does not disclose edge behavior like empty results or time-filter defaults, but these are minor for a read-only analytics tool and are partly covered by 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?
Three sentences front-load the core function, then give output fields, then an actionable next step. Every sentence earns its place with no redundant restatement 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?
With an output schema, 100% parameter coverage, and a readOnly annotation, the description provides the important missing context: what the rows represent and how to follow up on a vertex_id. It could be slightly sharper about the 'chat answers' scope versus the embed_types options, but it is functionally 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%, and the schema already documents limit, embed_types, and time_filter with defaults and formats. The description adds no parameter-specific detail beyond the schema, so the 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?
The description states a specific object (knowledge-base nodes), metric (citation count), and ordering (ranked by count), and enumerates the row fields. This clearly differentiates it from sibling tools like get_top_searches or get_top_clicked_urls.
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 gives an explicit use case ('understand which knowledge is actually load-bearing') and recommends pairing with read_node(vertex_id) for follow-up. It does not explicitly contrast with all sibling analytics tools, but the context is clear enough for an agent to select it for node-citation analytics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
URLs users actually clicked from inside the embed (search results, citation links, follow-ups, etc.), ranked by click count. Optionally filter by click event type. Use this to see what users find useful enough to click through to.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of rows to return, ordered by count descending. | |
| event_types | No | Restrict to specific click-event type(s): 'search_result', 'link', 'contact', 'tool', 'follow_up_navigation', 'follow_up_question'. Omit to include all. | |
| time_filter | No | Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive). | last_30_days |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, and the description adds useful context about what counts as a click (search results, citation links, follow-ups) and the ranking behavior. No behavior contradicts the readOnlyHint.
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 the core behavior front-loaded and no filler. The alternative purpose is communicated immediately before the optional filter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only analytics tool with three optional well-described parameters and an output schema, the description covers the essential selection criteria. It does not need to explain return values since an output schema exists, though explicit sibling routing would make it fully complete.
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 description does not need to re-document parameters. The only added hint is the optional event-type filter; the schema handles details, though its enumerated event-type list is slightly inconsistent with the property description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns URLs clicked from inside the embed, ranked by click count, which is a precise verb+resource. It also distinguishes itself from related analytics siblings like get_top_cited_sources by emphasizing actual click-through behavior rather than citations or searches.
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 gives an actionable use case: 'Use this to see what users find useful enough to click through to.' It does not explicitly name alternatives or exclusion conditions, but the context is clear enough that an agent can select it for click-engagement questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top device categories (e.g. 'desktop', 'mobile', 'tablet') across all request types, ranked by occurrence count. Use this to understand the device mix of real users interacting with the embed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of rows to return, ordered by count descending. | |
| time_filter | No | Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive). | last_30_days |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds useful scoping ('across all request types') and ordering semantics, but does not disclose data freshness, counting caveats, or any behavioral surprises. This is similar to the calibrated get_calls example.
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 tight sentences carry the key decision-relevant facts: what is returned, how it is ranked, and when to use it. There is no filler or 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, non-required, read-only analytics tool with a full output schema and fully documented parameters, the description covers everything an agent needs to call it correctly. The examples of device categories remove ambiguity about the return values.
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 time_filter fully documented in the schema including defaults, enum values, and date range patterns. The description adds no parameter-level meaning beyond the schema, 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 names the resource ('device categories'), the ordering ('ranked by occurrence count'), the population ('across all request types', 'real users interacting with the embed'), and gives concrete category examples. This makes it clearly distinguishable from sibling analytics tools such as get_top_geographies or get_top_languages.
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 provides an explicit intended use case: 'Use this to understand the device mix of real users interacting with the embed.' However, it does not name alternative tools or describe when not to use it, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top (country, region) combinations across all request types, ranked by occurrence count. Country is an ISO country code; region may be null when unavailable. Use this to understand geographic distribution of users.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of rows to return, ordered by count descending. | |
| time_filter | No | Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive). | last_30_days |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds useful behavioral details beyond annotations: the result is scoped 'across all request types,' rows are sorted by occurrence count, and 'region may be null when unavailable,' which clarifies expected output shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying distinct information: result shape, data semantics, and intended use. There is no redundant filler or 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 low-complexity, read-only tool with fully documented optional parameters and an output schema present, the description covers purpose, sorting, null behavior, and scope. Nothing essential is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; both the limit and time_filter parameters are fully documented with defaults, formats, and meaning. The description does not add parameter-specific semantics but does not need to, 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 the resource precisely ('Top (country, region) combinations'), the ordering criterion ('ranked by occurrence count'), and the purpose ('understand geographic distribution of users'). This clearly differentiates it from sibling analytics tools like get_top_languages or get_top_devices.
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 ('Use this to understand geographic distribution of users') and clarifies that results span 'all request types.' However, it does not explicitly mention when not to use it or name an alternative tool for related dimensions, so it stops short of a full usage guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Page URLs the user was ON when they interacted with the embed (chat, search, navigation, form submission), ranked by occurrence count. Differs from get_top_clicked_urls: this is the ORIGIN page, not the destination. Use this to find which pages of the host site drive the most embed engagement.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of rows to return, ordered by count descending. | |
| time_filter | No | Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive). | last_30_days |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the behavioral detail that results are ranked by occurrence count and refer to interaction contexts (chat, search, navigation, form submission). This is useful but modest; it does not go into response format or filtering behavior, though an output schema exists.
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 compact and immediately front-loads the core meaning. Each sentence adds value: what is returned, how it differs from a sibling, and when to use it. There is no redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only analytics tool with two optional, fully documented parameters and an output schema, the description covers the essential context. It explains the data semantics, ranking, and the key distinction from the most similar sibling, making the tool complete enough for correct selection and 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?
Input schema coverage is 100% for both optional parameters, including defaults, allowed enum values, and the custom date-range pattern. The description adds no parameter-specific information, which is acceptable because the schema already fully documents limit and time_filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair, 'get top interaction sources,' and states the exact meaning: page URLs the user was on when interacting with the embed, ranked by occurrence count. It also explicitly distinguishes this from get_top_clicked_urls, making the tool's identity 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 names a direct sibling, get_top_clicked_urls, and clarifies the key differentiator: origin page versus destination. It also states a clear use case, finding which host-site pages drive embed engagement. It lacks an explicit 'when not to use' instruction, but the contrast with get_top_clicked_urls effectively covers the main alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top detected natural languages of user CHAT questions, ranked by occurrence count. Differs from get_top_locales: locale reflects the embed/browser setting, language is detected from the actual query text. Use both to spot mismatches (e.g. German-speaking users hitting an English-only embed).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of rows to return, ordered by count descending. | |
| time_filter | No | Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive). | last_30_days |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description correctly does not contradict them. The description adds behavioral context by explaining the semantic difference between detected language and locale, and states the ordering basis ('ranked by occurrence count'). This goes beyond the annotation data and helps the agent understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences, each meaningful. The first sentence states the core purpose, the second clarifies the distinction from a sibling, and the third gives a practical use case. There is no redundant or filler content, and the key differentiating information is 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?
The tool has two optional parameters, full schema documentation, an output schema, and readOnly annotations. The description provides enough conceptual clarity for selection and invocation, and the existing structured metadata covers parameter details and safety. Nothing critical is missing for an agent to correctly use this 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 description coverage is 100%, as both limit and time_filter have detailed descriptions with defaults and constraints. The tool description does not need to add parameter-specific semantics; the baseline of 3 applies because the schema already carries the burden and the description adds no extra parameter insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns top detected natural languages of user CHAT questions ranked by occurrence count. It also explicitly differentiates from get_top_locales by explaining the conceptual distinction between detected language and locale, making the tool's purpose specific and distinguishable from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names get_top_locales as the alternative and explains the key difference: locale reflects embed/browser setting, while language is detected from actual query text. The description also provides a concrete use case ('spot mismaches e.g. German-speaking users hitting an English-only embed'), giving clear guidance on when and why to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top locales (BCP-47 style, e.g. 'de_DE', 'en_US') across chat, search, and navigation requests, ranked by occurrence count. Use this to understand which languages/regions are being served and where content gaps may exist.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of rows to return, ordered by count descending. | |
| time_filter | No | Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive). | last_30_days |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and openWorldHint=false, the safety profile is already clear. The description adds useful behavioral context by specifying the data scope ('across chat, search, and navigation requests') and the ranking by occurrence count. It does not overclaim side effects or 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?
Two concise sentences: the first defines exactly what the tool returns, and the second gives a practical use case. There is no filler, and the most identifying information is 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 simple two-parameter schema, rich schema descriptions, output schema, and read-only annotations, the description is nearly complete. It could still strengthen selection accuracy by explicitly differentiating from get_top_languages, but it otherwise provides enough context 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?
The input schema already covers all parameters with detailed descriptions and defaults, so the description carries no parameter burden. Baseline 3 applies because the description adds no extra parameter detail beyond what the schema provides.
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 names the resource (locales), defines them with BCP-47-style examples, and states they are ranked by occurrence count across chat, search, and navigation requests. This distinguishes the tool from siblings like get_top_languages and get_top_geographies by focusing on combined language/region locale data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit intended use: understanding which languages/regions are served and where content gaps may exist. It does not explicitly mention when not to use it or name alternatives such as get_top_languages, so it falls short of the highest level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top user search queries (normalized: lowercased, trimmed), ranked by occurrence count. Use this to discover dominant user intents and content gaps; pair with read_sessions(search_query=...) to inspect specific sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of rows to return, ordered by count descending. | |
| time_filter | No | Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive). | last_30_days |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, and the description adds meaningful behavioral details: results are normalized (lowercased/trimmed) and ranked by occurrence count. It also positions the tool as a high-level analytics entry point, which informs the agent's expectations about granularity.
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 filler: the first delivers the core result and normalization behavior, the second explains why and how to use it. Every sentence earns its place and the most important information is 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 low parameter count, high schema coverage, output schema presence, and read-only annotations, the description is complete. It adds the key non-obvious context—normalization, ranking, and the recommended pairing with read_sessions—leaving no critical gap for an agent 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 description coverage is 100%, so the schema fully documents both 'limit' and 'time_filter' parameters, including defaults and formats. The description adds no parameter-specific meaning beyond what the schema already provides, so 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?
States a specific verb and resource ('get top searches') and describes exactly what is returned: normalized, lowercased, trimmed user search queries ranked by occurrence count. The normalization detail adds precision and helps distinguish this from sibling analytics tools like get_top_clicked_urls or get_top_cited_sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool ('discover dominant user intents and content gaps') and provides a concrete complementary workflow: pair with read_sessions(search_query=...) to inspect specific sessions. This is clear, actionable guidance that routes the agent appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top tags attached to chat answers (auto-derived classifications), ranked by occurrence count. Optionally restrict to specific answer types. Use this for a quick topical breakdown of chat traffic.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of rows to return, ordered by count descending. | |
| time_filter | No | Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive). | last_30_days |
| answer_types | No | Restrict to chat requests whose final answer matched one of these types. Omit to include all answer types. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true, so the read-only character is covered. The description adds that tags are auto-derived and results are ranked by count, which is light but useful semantic context. 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?
Two sentences, roughly 20 words, with the core behavior in the first sentence and usage context in the second. There is no filler or redundant 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 simple list query with a fully documented 3-parameter schema and an output schema, the description covers purpose and use case. It doesn't explain tag semantics or edge cases, but nothing essential for selecting and invoking the tool 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%, and the description doesn't need to add parameter details. It does briefly echo the answer_types restriction ('Optionally restrict to specific answer types'), which maps to the parameter, but otherwise relies on the rich 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?
States a specific resource ('tags attached to chat answers') and ranking criterion ('by occurrence count'), with the parenthetical clarifying that tags are auto-derived classifications. It clearly describes a read operation for topical breakdown, though it doesn't explicitly distinguish itself from siblings like get_trending_classifications or get_answer_type_distribution.
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 final sentence 'Use this for a quick topical breakdown of chat traffic' supplies an explicit usage context. It does not mention when not to use it or name alternative tools, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Time series of trending classifications (topics OR intents inferred from chat content), one series per classification id. Each series item carries a period timestamp and count. Use this to see how topical or intent demand shifts over time. Choose 'topic' for subject-matter trends, 'intent' for user-goal trends.
| Name | Required | Description | Default |
|---|---|---|---|
| time_filter | No | Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive). | last_30_days |
| classification_type | Yes | Which classification dimension to trend: 'topic' or 'intent'. Topics = subject matter inferred from chat content; intents = user goal inferred from chat content. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds useful behavioral context beyond the schema: it explains the output shape (time series, one per classification id, each item with period timestamp and count), and clarifies that classifications are inferred from chat content. This is meaningful behavioral disclosure.
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. The main purpose is front-loaded, followed by output structure and parameter selection guidance. Every sentence adds value and the length is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only analytics tool with only two parameters and a full output schema, the description covers what the tool does, what it returns, and how to choose the classification type. The input schema documents time_filter, and annotations cover the read-only nature, so nothing critical 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 both parameters are already thoroughly documented in the input schema. The description largely repeats the classification_type semantics from the schema rather than adding substantial new meaning. It meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving time series of trending classifications (topics or intents), with one series per classification id. It explicitly distinguishes between topic and intent, which differentiates it from sibling analytics tools focused on other dimensions like sentiment or active sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context ('Use this to see how topical or intent demand shifts over time') and explains when to choose 'topic' versus 'intent'. It does not explicitly name alternative sibling tools or provide exclusion criteria, but the guidance is sufficient for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List data sources for the authenticated application. Optionally filter by data source type(s). Returns paginated results ordered by last update.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| data_source_types | No | Filter by data source type(s): 'website_crawler', 'pdf_upload', 'open_api', 'helpspace', 'custom_webcrawler', 'webhook'. Returns all when omitted. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description is not burdened with safety disclosure. It adds context about the authenticated scope, paginated results, and ordering by last update, which exceeds the structured annotation information. No side effects or rate-limit warnings are needed for an obviously read-only list operation.
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 and contains no filler. It front-loads the core action and then covers filtering and result behavior, with every sentence contributing useful 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 simple read-only listing tool, the description covers the resource, auth scope, optional filtering, pagination, and ordering, and the output schema supplies return structure. It does not explicitly state that omitting the filter returns all data sources, though the schema property mentions it. The enum/value mismatch in the schema is a small gap in overall completeness.
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 only 33%, and the main description says only 'Optionally filter by data source type(s)' without detailing page or limit. More seriously, the schema property description for data_source_types lists values like 'pdf_upload', 'open_api', and 'custom_webcrawler' that do not match the actual enum values ('file_upload', 'openAPI', 'custom_website_crawler'), which could mislead an agent. The description does not compensate for this inconsistency.
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: 'List data sources for the authenticated application.' It also states optional filtering and pagination/ordering, making its scope unambiguous. While it does not name a sibling tool, no sibling overlaps with this resource's list operation, so distinction is 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 description establishes when to use the tool: to list the authenticated app's data sources, optionally filtered by type. It does not mention alternatives or exclusions, but the sibling set contains update_data_source and analytics endpoints that serve different purposes, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List nodes in the knowledge base. Optionally filter by vertex label(s), data source type(s), or data source IDs. Optionally sort by updated_at ('asc' or 'desc'). Provide 'query' and 'locale' to perform a full-text search across node content (requires both parameters). Returns paginated results with total count.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| query | No | Full-text search query across node content. When provided, 'locale' must also be provided. Leave empty to list without search. | |
| labels | No | Filter by vertex label(s) (e.g. 'content'). Returns all when omitted. | |
| locale | No | Valid Locale configured in the application for full-text search (e.g. 'de', 'en'). Required when 'query' is provided. Ignored otherwise. | |
| data_source_ids | No | Filter by data source UUID(s). Returns all when omitted. | |
| sort_parameters | No | Sort order, e.g. [{"field": "updated_at", "direction": "desc"}]. | |
| data_source_types | No | Filter by data source type(s): 'website_crawler', 'pdf_upload', 'open_api', 'helpspace', 'custom_webcrawler', 'webhook'. Returns all when omitted. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is clear. The description adds value beyond annotations by explicitly stating that 'query' and 'locale' must both be provided for full-text search and that results are paginated with a total count.
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 focused sentences: it states the core purpose, lists the available optional behaviors, and notes the search precondition and pagination. Every sentence contributes distinct information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter optional-filter list tool with a rich input schema and an output schema, the description sufficiently covers the key invocation details: filters, sorting, search requirements, and pagination. An agent has enough context to call this tool correctly without needing the description to repeat schema or return-format details.
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 75%, so most parameters are already documented with defaults, enums, and conditions. The description reiterates the query/locale coupling and mentions filter dimensions, but it does not add substantial semantic meaning beyond what the input schema already provides.
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 'List nodes in the knowledge base,' clearly identifying the verb and resource. It further specifies optional filtering by labels, data source types/IDs, sorting, and full-text search, which distinguishes it from sibling tools like read_node and list_data_sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: listing nodes with optional filters, sorting, and paginated full-text search. It does not explicitly name alternatives or state when not to use this tool, but the usage context is unambiguous enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List prompts for the authenticated application. Optionally filter by type, subtype, or active status. Returns paginated results ordered by active status then last update.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| subtype | No | 'routing_instructions' or 'output_instructions'. Returns all when omitted. | |
| is_active | No | Activating a prompt automatically deactivates other prompts of the same type. | |
| prompt_type | No | 'chat', 'search_answering', 'suggested_questions', or 'chat_evaluation'. Returns all when omitted. | |
| interface_type | No | Interface scope of the prompt: 'chat', 'navigator', 'search', or 'api'. Required for 'chat' and 'search_answering' prompt types; omit for 'suggested_questions' and 'chat_evaluation'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only, and the description adds useful behavioral context: it returns paginated results ordered by active status then last update, and supports optional filters. This goes beyond the annotation without 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?
The description is two sentences, front-loaded with the core action, and every clause adds information: scope, optional filters, pagination, and ordering. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list operation with an output schema, the description covers purpose, scope, filtering options, and result ordering. It doesn't explicitly mention the page/limit parameters or interface_type as a filter, but the schema covers those, so the description remains 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 coverage is 67% and the schema already provides descriptions for subtype, is_active, prompt_type, and interface_type. The description's mention of filtering by 'type, subtype, or active status' is helpful but redundant and omits interface_type; page and limit are left to the schema, which lacks descriptions for them.
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: "List prompts for the authenticated application." It clearly distinguishes this list operation from sibling creation/update/read tools like create_prompt, update_prompt, and read_node, and adds scoping and result-ordering details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever the agent needs to list or filter prompts for the current application. It does not explicitly name alternatives or exclusions, but the list-vs-read/create context among siblings is clear enough for a straightforward enumeration tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tools configured for the authenticated application. Optionally filter by active status. Returns all matching tools.
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | true = active only, false = inactive only, omit = all. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is established. The description adds useful behavioral context by specifying the scope ('configured for the authenticated application') and stating that it 'Returns all matching tools', which clarifies that this is a complete list rather than a partial result. No contradictions 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 two short sentences with no filler. It leads with the core purpose, adds the optional filter, and closes with a meaningful return-behavior statement. 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 simple read-only list tool with one optional, fully-documented parameter and an output schema present, the description is complete. It conveys scope, filtering, and that all matching tools are returned, so an agent has enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the active parameter clearly documented as 'true = active only, false = inactive only, omit = all.' The description's mention of filtering by active status adds no meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'tools configured for the authenticated application', and it notes the optional active-status filter. It does not explicitly differentiate from the sibling read_tool, but 'List' versus 'read' plus the plural 'tools' makes the distinction reasonably 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 description gives no explicit guidance about when to choose this tool over alternatives such as read_tool or update_tool. It implies usage through the verb 'List', but does not state when listing is appropriate, what preconditions exist, or when a different tool should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full document chunks retrieved for a single chat request (QA or SA). Returns chunk_id, vertex_id, title, full text, score, source, data source type, page metadata, and whether the chunk was cited in the final answer. Use this after read_session_detail to inspect the exact context the assistant grounded its answer in. Ordered by score descending.
| Name | Required | Description | Default |
|---|---|---|---|
| chat_request_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Read-only behavior is already covered by readOnlyHint=true; the description adds useful behavioral details such as returning full text, indicating whether a chunk was cited, and ordering results by score descending. No contradictions 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?
Two compact sentences with a front-loaded purpose, a precise return-field list, workflow guidance, and ordering information. Every clause 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 one-parameter read-only tool with an output schema, this covers purpose, workflow position, return content, and ordering. An agent has enough information to select and 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 description clarifies that the tool operates 'for a single chat request' and tells the agent to call it after read_session_detail, indicating where the chat_request_id comes from. Although it doesn't discuss the parameter by name, the single self-describing UUID parameter is sufficiently contextualized.
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 and resource: 'Read the full document chunks retrieved for a single chat request.' Lists the exact returned fields and names the QA/SA context, making it clearly distinct from siblings like read_chat_request_tool_calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this after read_session_detail, establishing the correct workflow. It does not enumerate alternatives or when-not conditions, but the intended context is clear and useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full tool calls executed for a single chat request. Returns tool_call_id, tool_id, tool_name, tool_type, full arguments (JSON), and full content/response (JSON). Use this to inspect what the assistant invoked and how the tool responded. Ordered by timestamp ascending.
| Name | Required | Description | Default |
|---|---|---|---|
| chat_request_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which covers the safety profile. The description adds useful behavioral context beyond that: it returns the full arguments and content/response as JSON, and results are ordered by timestamp ascending. This is meaningful and non-redundant.
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 sentences, each earning its place: what it reads, what it returns, and why to use it. No filler or 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?
The tool is simple (one parameter, one resource) and has an output schema. The description covers the operation scope, return contents, ordering, and usage intent, so an agent has everything needed to select and 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?
The only parameter, chat_request_id, has no schema description (0% coverage), but the description compensates by tying the operation to 'a single chat request.' This makes the purpose of the required uuid parameter clear enough for 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 uses a specific verb ('Read') and resource ('full tool calls executed for a single chat request'), clearly distinguishing it from siblings like read_chat_request_documents or read_session_detail. It also enumerates the exact returned fields, removing ambiguity about what the agent will get.
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 states the intended use: 'Use this to inspect what the assistant invoked and how the tool responded.' This gives clear situational context, though it does not explicitly contrast with sibling tools or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List data source runs for the authenticated application, latest first. Optionally filter by data source ID or run status. Returns the latest runs (default 5) and the total matching count. Use this to track the progress of a run triggered via run_data_source.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No | Filter runs by status: 'started', 'succeeded', 'aborted', 'timeout', or 'cancelled'. Returns all when omitted. | |
| data_source_id | No | Filter runs by data source UUID. Returns all runs when omitted. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns with that. It adds valuable behavioral context: authenticated-application scoping, latest-first ordering, default limit of 5, and that the response includes both latest runs and a total matching count. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with front-loaded purpose, followed by filtering options, return summary, and intended use case. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, read-only annotations are present, and all parameters are optional, the description covers everything an agent needs: scope, ordering, default limit, result summary, and the specific use case. No critical 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?
Schema descriptions already cover status and data_source_id well, and the description reinforces them as optional filters. It adds the default-limit behavior ('default 5') for the limit parameter, which the schema mentions via default, and clarifies the output count. With 67% schema coverage, the description compensates reasonably without duplicating every detail.
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 resource ('data source runs'), scoped to the authenticated application, with ordering ('latest first') and optional filters. It is clearly distinguishable from siblings like run_data_source (triggering) and list_data_sources (listing sources).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames the intended use case: 'Use this to track the progress of a run triggered via run_data_source.' This names the related sibling tool and the condition under which this read tool is appropriate, giving agents clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a node by its ID. Returns full node details.
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is implied. The description adds the specific promise 'Returns full node details,' which goes beyond the annotation by specifying the output's completeness. It does not contradict annotations and adds useful context about what the caller can expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The action is front-loaded, and every word contributes value. It is appropriately terse for the tool's simplicity.
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 (as indicated), the description need not enumerate return fields. For a single-parameter read tool, the description covers the essential information: what to provide (node ID) and what to expect (full node details). No missing critical context 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 0%, so the description must compensate. However, the sole parameter node_id is self-explanatory and already documented in the schema as a UUID. The phrase 'by its ID' merely restates the parameter's purpose without adding new meaning. Given the trivial nature of the parameter, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete action ('Read a node') and resource ('by its ID'), clearly distinguishing it from siblings like list_nodes (which lists nodes without an ID) and create_node/update_node. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The statement 'Read a node by its ID' clearly implies the tool is used when you already have a specific node ID. While it does not explicitly contrast with list_nodes (e.g., 'use list_nodes to browse all nodes'), the context is unambiguous enough for an agent to decide. It lacks explicit exclusions but is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full search results returned for a single instant-search request. Returns chunk_id, vertex_id, title, full text, and relevance score. Use this to inspect the exact results a user saw for their search query. Ordered by score descending.
| Name | Required | Description | Default |
|---|---|---|---|
| search_request_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds useful behavioral context: it returns full text, includes relevance scores, and is ordered by score descending. It does not mention rate limits, auth, or payload size, but for a simple read operation with strong annotations 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?
Three short, information-dense sentences: purpose, returned fields, usage scenario, and ordering. No redundant wording or filler; 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 a single parameter and an output schema, the description covers the purpose, the key returned fields, ordering, and the use case. It doesn't explicitly mention alternatives or prerequisites, but given the tool's simplicity and the available annotations, it is sufficiently 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 0%, so the description must compensate for the sole parameter search_request_id. The description refers to 'a single instant-search request,' which contextualizes the ID as identifying that request. However, it doesn't explicitly describe the parameter's origin or format beyond what the parameter name and schema type (UUID) already convey.
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 ('Read') and resource ('full search results returned for a single instant-search request'), and lists the returned fields (chunk_id, vertex_id, title, full text, relevance score). This clearly distinguishes it from sibling tools like read_chat_request_documents by scoping to instant-search requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: 'inspect the exact results a user saw for their search query.' It does not explicitly name alternatives or provide when-not-to-use conditions, but the context is clear enough for an agent to select this tool over related read tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a single session with its full history in token-dense form. Returns all interactions (chat, navigation, search, form, voice). Document chunks and tool calls are returned as references (IDs + titles) - use read_node(vertex_id) or read_tool(tool_id) to fetch full content.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds valuable behavior: it returns all interaction types, returns document chunks/tool calls as references, and warns of the token-dense format. This goes beyond what annotations or 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?
Two sentences with no fluff. The puropse is front-loaded, and the second sentence adds critical return-format details plus pointers to alternative tools, each sentence earning 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?
With an output schema present, the return values are already documented. The description covers the token-dense behavior, the reference format, and where to get full content. The only minor gap is lack of pagination or size limit hints, but these are not critical for a simple read 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 description coverage is 0%, and the description does not add any parameter-specific guidance beyond the self-evident 'session_id'. It fails to mention that the ID should come from read_sessions or list_sessions, leaving the agent to infer it from the tool 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?
Description states a specific verb and resource: 'Read a single session with its full history in token-dense form'. It distinguishes from siblings like read_sessions (plural) and read_node/read_tool by defining the scпе and giving example use cases for the alternatives.
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 clearly instructs when to use read_nodе and read_tool for full content, which routes an agent to the right alternatives. It doesn't explicitly state when to prefer read_sessions over this toool, but the singular 'single session' implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sessions for application. Filter by interaction types (chat, search, navigation, form_submission, voice), embed types, answer types, tool IDs, or a full-text search query. Each session includes its full history, but document chunks and tool calls are returned as references (IDs + titles) rather than full content.Returns paginated results ordered by start time descending.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| tool_ids | No | Filter sessions that involved specific tool UUID(s). Only exists for chat sessions. | |
| embed_types | No | Filter by embed type(s) through which sessions were initiated. | |
| time_filter | No | Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive). | |
| answer_types | No | Filter by answer type(s) returned to users. Only exists for chat sessions. | |
| interactions | No | 'chat', 'search', 'navigation', 'form_submission', or 'voice'. | |
| search_query | No | Full-text search across session content. Returns all when omitted. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, and the description adds meaningful behavioral detail: sessions include full history, document chunks and tool calls are returned as references (IDs + titles) rather than full content, and results are paginated and ordered by start time descending. 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 concise and front-loaded with the core action and resource. The second sentence is dense but valuable; a minor formatting typo ('content.Returns') slightly detracts from polish.
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 8 parameters, high schema coverage, an output schema, and readOnly annotations, the description covers the important behavioral gaps: reference-only content, pagination, and ordering. It could mention default time_filter or page/limit behavior, but these are already in 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 75%, so the schema already documents most parameters, including time_filter formats and enum values. The description restates filters in prose but adds little semantic detail beyond what the schema provides.
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 and resource: 'List sessions for application.' It then enumerates the available filters (interactions, embed types, answer types, tool IDs, full-text search), making the tool's scope immediately clear and distinguishing it from siblings such as read_session_detail.
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 listing tool and what filtering capabilities it offers, but it does not explicitly contrast it with read_session_detail or other analytics siblings, nor does it state when not to use it. Usage context is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a tool by its ID. Returns full tool details.
| Name | Required | Description | Default |
|---|---|---|---|
| tool_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile, so the description's burden is lower. 'Returns full tool details' adds modest behavioral context, though the output schema already documents return values. Error behavior (e.g., behavior on a nonexistent ID) is not disclosed. 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?
Two short sentences with zero filler; the core purpose is front-loaded in the first sentence. Every word earns its place and there is no redundant restating of the schema 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?
The tool is simple (1 param, read-only, output schema present), and annotations plus the output schema carry the safety and return-value details. The description covers the core purpose but leaves gaps: it does not route the agent to list_tools for sourcing the ID or enumerating tools, and it lacks usage context. Adequate but not rich.
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, and it partially does: 'by its ID' maps tool_id to the tool's identifier, adding meaning beyond the bare schema (string, uuid format, required). For a single self-explanatory parameter this is adequate, but it adds no depth on format or constraints beyond what the schema states.
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 (Read) + resource (tool) + identifier qualifier (by its ID), making the purpose unmistakable. It implicitly distinguishes from list_tools (singular read vs. all tools). However, it does not explicitly name the siblings it is NOT (e.g., read_node), so it stops short of a 5.
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 guidance is given on when to use this tool versus list_tools (for enumerating tools) or update_tool (for modifying a tool). There is no 'use when' language, no mention of what the tool_id should come from, and no exclusions. The description is a single sentence with zero usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger an asynchronous run (sync/crawl) of a data source by its ID. The run is queued as a background job. Returns the accepted status. Track progress with read_data_source_runs.
| Name | Required | Description | Default |
|---|---|---|---|
| data_source_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing that the run is asynchronous, queued as a background job, returns only an accepted status, and that progress must be tracked elsewhere. This is exactly the behavioral context an agent needs beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The core action is front-loaded, and each sentence adds relevant information: trigger, async behavior, and follow-up tracking.
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 trigger tool with an output schema, the description covers the full workflow: initiate the run, understand the immediate result, and track progress via the indicated sibling. Nothing critical 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 schema has a single required data_source_id as a UUID, and the description only says 'by its ID.' While schema description coverage is 0%, the parameter is self-explanatory and the description reinforces its role. More detail on where to obtain the ID is not essential here.
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 ('Trigger') and resource ('run of a data source') and clearly distinguishes the action from read/update/create operations. It also points to read_data_source_runs for tracking, which differentiates it from the sibling that reads runs.
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 when to use this tool: when you want to start an asynchronous sync/crawl and only need an accepted status. It also tells the agent to use read_data_source_runs for progress, though it does not explicitly discuss exclusions or alternative trigger conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update analytics fields on a chat request: summary, tags, answer_type, sentiment, classification_topic_id, or classification_intent_id. Only provided fields are updated. Use this to annotate or reclassify chat interactions after the fact.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | List of tags to attach to the chat request. | |
| summary | No | Short summary or annotation for the chat request. | |
| sentiment | No | Sentiment classification: 'positive', 'negative', or 'neutral'. | |
| answer_type | No | Answer type classification: 'complete', 'no_knowledge', 'outside_scope', 'small_talk', or 'follow_up_question'. | |
| chat_request_id | Yes | ||
| classification_topic_id | No | UUID of the classification topic to assign to this chat request. | |
| classification_intent_id | No | UUID of the classification intent to assign to this chat request. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover non-destructive and idempotent behavior, so the bar is lower. The description adds meaningful partial-update semantics with 'Only provided fields are updated', which tells the agent that omitted fields remain unchanged.
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 concise sentences both earn their place: the first states the action, resource, and fields, and the second states the intended use case. Information is front-loaded with no 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?
The tool has a simple flat schema, an output schema, and annotations covering idempotency and destructive risk. The description sufficiently covers scope, behavior, and use case, leaving no critical gap for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (86%), so the schema already explains each parameter. The description adds value by grouping these as analytics fields and stating partial-update behavior, but it does not provide new per-parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Update analytics fields on a chat request') and lists all possible fields. It also distinguishes itself from sibling update_* tools by naming the chat-request resource and its analytics 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 phrase 'Use this to annotate or reclassify chat interactions after the fact' provides clear intended context. It does not explicitly name alternatives or exclusions, but no direct sibling alternative for this update operation exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a data source by its ID. Only provided fields will be updated (partial update). Returns the updated data source.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| type | No | Must match the 'type' discriminator of the 'settings' object when both are provided. | |
| schedule | No | Cron expression (e.g. '0 3 * * *') or null to disable scheduled re-sync. | |
| settings | No | Type-specific config. Pass as an inline JSON object — do NOT serialize to a string. Must include a 'type' discriminator field: 'website_crawler', 'pdf_upload', 'open_api', 'helpspace', 'custom_webcrawler', or 'webhook'. | |
| data_source_id | Yes | ||
| integration_id | No | Integration UUID for connected data sources. Required for WordPress data sources. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a write operation, non-destructive, and idempotent. The description adds useful behavior beyond annotations by stating partial-update semantics and that the updated data source is returned, but it does not disclose side effects such as what happens when type/settings are changed together.
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 tightly written sentences; the action is front-loaded and every clause earns its place. No filler or 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?
Despite a complex settings schema, the combination of concise description, rich input/output schemas, and annotations gives an agent enough to select and use the tool. The main gap is not naming create_data_source as the alternative for new data sources, but this is a minor omission.
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 67%, with useful descriptions for type, schedule, settings, and integration_id, so the schema carries most parameter meaning. The description adds no per-parameter details, though 'Only provided fields will be updated' contextualizes all optional parameters as omittable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Update a data source by its ID') and immediately clarifies the semantics with 'Only provided fields will be updated (partial update)'. This clearly separates it from creation/list/read/run siblings and from updates to other 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 for modifying an existing data source by its required ID, and the partial-update note tells agents they can omit unchanged fields. However, it does not explicitly state when not to use it or point to create_data_source as the alternative for new data sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a content node by its ID. Only provided fields are updated. Title and text are locale dicts (e.g. {"de": "Titel"}) — provided keys are merged, others preserved. custom_metadata keys are likewise merged into the existing metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Locale-keyed body content (HTML) map, e.g. {"de": "<p>Inhalt</p>", "en": "<p>Content</p>"}. | |
| title | No | Locale-keyed title map, e.g. {"de": "Titel", "en": "Title"}. | |
| source | No | Source URL for the node content. | |
| node_id | Yes | ||
| score_boost | No | Boost value for search ranking. Higher is better. Use null for no boost. | |
| custom_metadata | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond what annotations provide (idempotentHint, destructiveHint), the description discloses valuable behavioral traits: partial updates ('Only provided fields are updated') and deep-merge semantics for locale dicts and custom_metadata. This adds context that the annotations do not cover. No contradiction with the annotations is present.
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 tightly written sentences, front-loaded with the main operation and resource, followed by the critical merge semantics in a compact paragraph. Every sentence earns its place 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?
For a moderately complex update tool with 6 parameters, an output schema, and existing annotations, the description covers the essential behavior and the tricky merge rules. Minor omissions, such as error handling for a missing node_id or invalid locale keys, are not critical given the schema and output schema context.
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 67% schema description coverage, the description compensates by explaining the merge behavior for title and custom_metadata, and it clarifies that text follows the same locale-dict pattern. This adds meaningful semantic value over the raw schema properties.
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, resource, and selector: 'Update a content node by its ID.' This clearly distinguishes it from sibling tools like create_node (create) and read_node (read) without requiring the agent to inspect the schema.
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 for modifying an existing node, but it does not explicitly say when to prefer this over create_node or how it differs from update_prompt/update_tool. No exclusions or scenario guidance are provided, so the agent must infer the appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Activate or deactivate a prompt by its ID. Use is_active=true to restore a previous prompt version — the currently active prompt of the same type and subtype is deactivated automatically. To change prompt text, use create_prompt instead.
| Name | Required | Description | Default |
|---|---|---|---|
| is_active | No | Activating a prompt automatically deactivates other prompts of the same type. | |
| prompt_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations say this is a mutating, idempotent operation, but they do not reveal the important side effect that activating a prompt automatically deactivates the currently active prompt of the same type and subtype. The description surfaces this behavior and frames is_active=true as a restore action, which is essential context.
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 tightly crafted sentences: the first states the core action, the second provides behavioral nuance and the sibling alternative. No filler 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?
For a two-parameter state toggle with an output schema, this description is complete. It gives the purpose, the main side effect, and the alternative tool for text edits, so an agent has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers only is_active's meaning, leaving prompt_id undocumented. The description compensates by explaining is_active=true restores a previous version and triggers automatic deactivation of same-type/subtype prompts. prompt_id remains self-explanatory as a UUID, but no additional semantic detail is provided for it.
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 action: 'Activate or deactivate a prompt by its ID.' It also names the sibling it is not, stating 'To change prompt text, use create_prompt instead,' so an agent can distinguish update_prompt from create_prompt.
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 guidance is explicit: use is_active=true to restore a previous version, and use create_prompt when changing prompt text. The description also explains the automatic deactivation behavior, leaving little room for misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing tool by its ID. Fetches the current tool and applies partial updates to name, description, or active status.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | snake_case tool name, max 64 characters. Used as the function name when the LLM calls the tool. | |
| active | No | ||
| tool_id | Yes | ||
| description | No | ||
| tool_config | No | Function schema sent to the LLM. Pass as an inline JSON object — do NOT serialize to a string. Use 'FormAPISchema' for form tools or 'APIToolConfig' for API-calling tools. Pass null to clear. | |
| function_arguments | No | Fixed runtime arguments NOT collected from the LLM (e.g. recipient email, rerank flag, knowledge-base ID). Pass as an inline JSON object — do NOT serialize to a string. Must include an 'object' discriminator field matching the tool type. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond the annotations by disclosing that the tool fetches the current tool and applies partial updates, implying unspecified fields are preserved. This complements the idempotentHint and destructiveHint=false annotations, and 'active status' transparently signals a possible state-changing effect.
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 short sentences with no filler. The core update behavior is front-loaded, and the partial-update semantics are stated efficiently. 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?
Given the tool's large schema with six parameters and complex nested objects for tool_config and function_arguments, the description is somewhat incomplete: it mentions only three updatable fields and does not clarify whether or how the complex configuration parameters are updated. The rich schema and output schema mitigate this, but the description alone does not fully guide an agent through the full update surface.
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 description adds semantic context for name, description, and active status, which is helpful given 50% schema description coverage. However, it omits the two complex parameters, tool_config and function_arguments, even though these are important when updating a tool's behavior; the schema itself provides their detailed descriptions, partially compensating for this gap.
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 operation ('Update an existing tool'), the required identifier ('by its ID'), and the updatable fields (name, description, active status). It is unambiguous about operating on a tool resource and on mutation, though it does not explicitly distinguish itself from sibling update tools like update_prompt or update_data_source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when an existing tool needs to be modified, especially for partial updates. It does not list explicit exclusions or alternative tools, but the 'existing tool' and 'partial updates' phrasing makes the primary use case obvious.
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. Dates show when Glama detected each change.
create_data_sourcecreate_toolget_top_clicked_urls1 field changedInput schema / properties / event_types / anyOfPrevious value: -[
- {
- "items": {
- "enum": [
- "search_result",
- "link",
- "contact",
- "tool",
- "follow_up_navigation",
- "follow_up_question",
- "custom"
- ],
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "enum": [
+ "search_result",
+ "link",
+ "contact",
+ "tool",
+ "follow_up_navigation",
+ "follow_up_question",
+ "custom",
+ "analytics"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]read_data_source_runsrun_data_sourceupdate_data_source1 field changedInput schema / properties / integration_id / descriptionPrevious value: -"Integration UUID for connected data sources (e.g. WordPress). Required when updating a WordPress data source."New value: +"Integration UUID for connected data sources. Required for WordPress data sources."update_tool1 field changedInput schema / properties / function_arguments / anyOfPrevious value: -[
- {
- "properties": {
- "data_source_ids_filter": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "data_source_types_filter": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "website_crawler",
- "file_upload",
- "node_editor",
- "default_node",
- "openAPI",
- "helpspace",
- "custom_website_crawler",
- "webhook",
- "wordpress"
- ],
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "document_limit_default": {
- "default": 15,
- "type": "integer"
- },
- "document_limit_rerank": {
- "default": 25,
- "type": "integer"
- },
- "formatter": {
- "default": "chunks_with_source",
- "enum": [
- "chunks_with_source",
- "numbered_chunks_with_source",
- "grouped_chunks",
- "grouped_chunks_with_custom_metadata",
- "grouped_chunks_with_page_metadata"
- ],
- "type": "string"
- },
- "node_ids_filter": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "node_labels_filter": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "entry",
- "content",
- "contact",
- "tool",
- "fallback",
- "integration",
- "style",
- "chat_navigator_style",
- "search_style",
- "search_result",
- "navigator",
- "feedback"
- ],
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "object": {
- "const": "knowledge_base_tool_arguments",
- "default": "knowledge_base_tool_arguments",
- "type": "string"
- },
- "rerank": {
- "default": false,
- "type": "boolean"
- },
- "retrieval_method": {
- "default": "default",
- "enum": [
- "default",
- "parent_context"
- ],
- "type": "string"
- },
- "sources_filter": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "node_ids": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "object": {
- "const": "node_lookup_tool_arguments",
- "default": "node_lookup_tool_arguments",
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "object": {
- "const": "send_email_tool_arguments",
- "default": "send_email_tool_arguments",
- "type": "string"
- },
- "sender_email": {
- "format": "email",
- "type": "string"
- }
- },
- "required": [
- "sender_email"
- ],
- "type": "object"
- },
- {
- "properties": {
- "limit": {
- "default": 5,
- "type": "integer"
- },
- "object": {
- "const": "web_search_tool_arguments",
- "default": "web_search_tool_arguments",
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "object": {
- "const": "web_page_reader_tool_arguments",
- "default": "web_page_reader_tool_arguments",
- "type": "string"
- },
- "target_selector": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Only returns elements from CSS selector."
- },
- "url": {
- "type": "string"
- },
- "wait_for_selector": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Wait for a specific element to appear before returning. For dynamic content."
- }
- },
- "required": [
- "url"
- ],
- "type": "object"
- },
- {
- "properties": {
- "data_privacy_text": {
- "anyOf": [
- {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional data privacy text. If provided, a checkbox should be displayed to the user."
- },
- "form_title": {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- "notification_email": {
- "anyOf": [
- {
- "format": "email",
- "type": "string"
- },
- {
- "items": {
- "format": "email",
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Used for email forwarding of form submissions. If not provided, no email will be forwarded"
- },
- "object": {
- "const": "form_tool_arguments",
- "default": "form_tool_arguments",
- "type": "string"
- },
- "show_data_privacy_text": {
- "default": false,
- "type": "boolean"
- },
- "submit_button_text": {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- "submit_message": {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- }
- },
- "required": [
- "form_title",
- "submit_message",
- "submit_button_text"
- ],
- "type": "object"
- },
- {
- "properties": {
- "channels": {
- "type": "string"
- },
- "domain": {
- "type": "string"
- },
- "entity_type": {
- "const": "Event",
- "default": "Event",
- "type": "string"
- },
- "event": {
- "anyOf": [
- {
- "properties": {
- "event_type": {
- "enum": [
- "carousel_v1"
- ],
- "type": "string"
- },
- "mapping": {
- "properties": {
- "detail": {
- "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
- "type": "string"
- },
- "id": {
- "default": "{{event_id}}",
- "type": "string"
- },
- "image_url": {
- "default": "{{first_image.url}}",
- "type": "string"
- },
- "resource_url": {
- "default": "{{link}}",
- "type": "string"
- },
- "tags": {
- "default": "{{tags}}",
- "type": "string"
- },
- "title": {
- "default": "{{event_name}}",
- "type": "string"
- },
- "type": {
- "const": "carousel_v1",
- "default": "carousel_v1",
- "type": "string"
- }
- },
- "type": "object"
- }
- },
- "required": [
- "event_type",
- "mapping"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional frontend event mapping."
- },
- "object": {
- "const": "venus_knowledge_graph_tool_arguments",
- "default": "venus_knowledge_graph_tool_arguments",
- "type": "string"
- },
- "projects": {
- "type": "string"
- }
- },
- "required": [
- "projects",
- "channels",
- "domain"
- ],
- "type": "object"
- },
- {
- "properties": {
- "event": {
- "anyOf": [
- {
- "properties": {
- "event_type": {
- "enum": [
- "carousel_v1"
- ],
- "type": "string"
- },
- "mapping": {
- "properties": {
- "detail": {
- "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
- "type": "string"
- },
- "id": {
- "default": "{{event_id}}",
- "type": "string"
- },
- "image_url": {
- "default": "{{first_image.url}}",
- "type": "string"
- },
- "resource_url": {
- "default": "{{link}}",
- "type": "string"
- },
- "tags": {
- "default": "{{tags}}",
- "type": "string"
- },
- "title": {
- "default": "{{event_name}}",
- "type": "string"
- },
- "type": {
- "const": "carousel_v1",
- "default": "carousel_v1",
- "type": "string"
- }
- },
- "type": "object"
- }
- },
- "required": [
- "event_type",
- "mapping"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional frontend event mapping."
- },
- "object": {
- "const": "regiondo_tool_arguments",
- "default": "regiondo_tool_arguments",
- "type": "string"
- },
- "public_key": {
- "type": "string"
- },
- "secret_key": {
- "type": "string"
- }
- },
- "required": [
- "secret_key",
- "public_key"
- ],
- "type": "object"
- },
- {
- "properties": {
- "events": {
- "description": "List of frontend events to be triggered by this tool",
- "items": {
- "properties": {
- "event_type": {
- "enum": [
- "carousel_v1"
- ],
- "type": "string"
- },
- "mapping": {
- "properties": {
- "detail": {
- "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
- "type": "string"
- },
- "id": {
- "default": "{{event_id}}",
- "type": "string"
- },
- "image_url": {
- "default": "{{first_image.url}}",
- "type": "string"
- },
- "resource_url": {
- "default": "{{link}}",
- "type": "string"
- },
- "tags": {
- "default": "{{tags}}",
- "type": "string"
- },
- "title": {
- "default": "{{event_name}}",
- "type": "string"
- },
- "type": {
- "const": "carousel_v1",
- "default": "carousel_v1",
- "type": "string"
- }
- },
- "type": "object"
- },
- "mcp_tool_entities": {
- "anyOf": [
- {
- "properties": {
- "key": {
- "description": "The key to use to identify the entity from the MCP server response",
- "type": "string"
- },
- "values": {
- "description": "The specific entities (values) that should be mapped to the frontend event",
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "required": [
- "key"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "description": "Mapping to distinguish entities from the MCP server response. If None, map to all entities"
- },
- "mcp_tool_names": {
- "description": "List of tool names this frontend event should be mapped to. If empty, map to all tools of the MCP server.",
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "required": [
- "event_type",
- "mapping",
- "mcp_tool_entities"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "headers": {
- "anyOf": [
- {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional headers to be sent with the request to the MCP server."
- },
- "image_url": {
- "anyOf": [
- {
- "format": "uri",
- "minLength": 1,
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional image URL to be shown in the Dashboard. Only for frontend display."
- },
- "mcp_url": {
- "format": "uri",
- "minLength": 1,
- "type": "string"
- },
- "object": {
- "const": "mcp_server_tool_arguments",
- "default": "mcp_server_tool_arguments",
- "type": "string"
- }
- },
- "required": [
- "mcp_url"
- ],
- "type": "object"
- },
- {
- "description": "Arguments for the API tool that define how to make HTTP requests.\n\nContains the static configuration for executing API requests.\nUse {{parameter_name}} mustache notation in url, query_params, headers, and body\nto reference parameters defined in tool_config.",
- "properties": {
- "body": {
- "anyOf": [
- {
- "additionalProperties": true,
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Request body. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
- },
- "body_content_type": {
- "default": "application/json",
- "description": "Content type of the request body.",
- "enum": [
- "application/json",
- "application/x-www-form-urlencoded"
- ],
- "type": "string"
- },
- "event": {
- "anyOf": [
- {
- "properties": {
- "event_type": {
- "enum": [
- "carousel_v1"
- ],
- "type": "string"
- },
- "mapping": {
- "properties": {
- "detail": {
- "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
- "type": "string"
- },
- "id": {
- "default": "{{event_id}}",
- "type": "string"
- },
- "image_url": {
- "default": "{{first_image.url}}",
- "type": "string"
- },
- "resource_url": {
- "default": "{{link}}",
- "type": "string"
- },
- "tags": {
- "default": "{{tags}}",
- "type": "string"
- },
- "title": {
- "default": "{{event_name}}",
- "type": "string"
- },
- "type": {
- "const": "carousel_v1",
- "default": "carousel_v1",
- "type": "string"
- }
- },
- "type": "object"
- }
- },
- "required": [
- "event_type",
- "mapping"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional frontend event mapping."
- },
- "headers": {
- "anyOf": [
- {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "HTTP headers for the request. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
- },
- "method": {
- "description": "HTTP method for the API request.",
- "enum": [
- "GET",
- "POST",
- "PUT",
- "PATCH",
- "DELETE"
- ],
- "type": "string"
- },
- "object": {
- "const": "api_tool_arguments",
- "default": "api_tool_arguments",
- "type": "string"
- },
- "query_params": {
- "anyOf": [
- {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Query parameters for the request. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
- },
- "response_path": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional dot notation to extract specific data from the API response."
- },
- "timeout": {
- "default": 5,
- "description": "Request timeout in seconds.",
- "maximum": 30,
- "minimum": 1,
- "type": "integer"
- },
- "url": {
- "description": "URL of the API endpoint. Can include parameter placeholders using mustache notation like {{parameter_name}}.",
- "type": "string"
- }
- },
- "required": [
- "method",
- "url"
- ],
- "type": "object"
- },
- {
- "description": "Arguments for the Buttons tool.\n\nThis tool allows AI to send buttons as a frontend event to users.\nNo inputs are required from the AI when executing this tool.\nMaximum 3 buttons can be sent.",
- "properties": {
- "buttons": {
- "description": "List of buttons to display. Maximum 10 buttons.",
- "items": {
- "description": "Individual button in the buttons tool.\n\n- link_button: Opens URL in new tab (if external) or navigates (like follow-up actions)\n- button: Uses text as input for sending new request",
- "properties": {
- "text": {
- "description": "Button text to display. Should be short and descriptive.",
- "maxLength": 50,
- "type": "string"
- },
- "type": {
- "description": "Type of the button",
- "enum": [
- "link_button",
- "button"
- ],
- "type": "string"
- },
- "url": {
- "anyOf": [
- {
- "format": "uri",
- "minLength": 1,
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "URL for link_button type. Required for link_button, not used for button type. Allow mailto: and tel: links as well."
- }
- },
- "required": [
- "type",
- "text"
- ],
- "type": "object"
- },
- "maxItems": 10,
- "minItems": 1,
- "type": "array"
- },
- "object": {
- "const": "buttons_tool_arguments",
- "default": "buttons_tool_arguments",
- "type": "string"
- }
- },
- "required": [
- "buttons"
- ],
- "type": "object"
- },
- {
- "properties": {
- "default_travelmode": {
- "anyOf": [
- {
- "enum": [
- "driving",
- "walking",
- "bicycling",
- "transit"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Default travel mode used when the AI does not specify one."
- },
- "icon_url": {
- "anyOf": [
- {
- "format": "uri",
- "minLength": 1,
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional URL of an icon to display inside the link button."
- },
- "object": {
- "const": "google_maps_link_tool_arguments",
- "default": "google_maps_link_tool_arguments",
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "default_mode": {
- "anyOf": [
- {
- "enum": [
- "driving",
- "walking",
- "bicycling",
- "transit",
- "flying"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Default travel mode used when the AI does not specify one."
- },
- "object": {
- "const": "google_maps_embed_tool_arguments",
- "default": "google_maps_embed_tool_arguments",
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "integration_id": {
- "description": "ID of the connected Calendly integration to use for scheduling.",
- "format": "uuid",
- "type": "string"
- },
- "object": {
- "const": "calendly_tool_arguments",
- "default": "calendly_tool_arguments",
- "type": "string"
- }
- },
- "required": [
- "integration_id"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "properties": {
+ "data_source_ids_filter": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "data_source_types_filter": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "website_crawler",
+ "file_upload",
+ "node_editor",
+ "default_node",
+ "openAPI",
+ "helpspace",
+ "custom_website_crawler",
+ "webhook",
+ "wordpress"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "document_limit_default": {
+ "default": 15,
+ "type": "integer"
+ },
+ "document_limit_rerank": {
+ "default": 25,
+ "type": "integer"
+ },
+ "formatter": {
+ "default": "chunks_with_source",
+ "enum": [
+ "chunks_with_source",
+ "numbered_chunks_with_source",
+ "grouped_chunks",
+ "grouped_chunks_with_custom_metadata",
+ "grouped_chunks_with_page_metadata"
+ ],
+ "type": "string"
+ },
+ "node_ids_filter": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "node_labels_filter": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "entry",
+ "content",
+ "contact",
+ "tool",
+ "fallback",
+ "integration",
+ "style",
+ "chat_navigator_style",
+ "search_style",
+ "search_result",
+ "navigator",
+ "feedback"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "object": {
+ "const": "knowledge_base_tool_arguments",
+ "default": "knowledge_base_tool_arguments",
+ "type": "string"
+ },
+ "rerank": {
+ "default": false,
+ "type": "boolean"
+ },
+ "retrieval_method": {
+ "default": "default",
+ "enum": [
+ "default",
+ "parent_context"
+ ],
+ "type": "string"
+ },
+ "sources_filter": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "node_ids": {
+ "description": "List of node IDs to look up in the graph.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "object": {
+ "const": "node_lookup_tool_arguments",
+ "default": "node_lookup_tool_arguments",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "object": {
+ "const": "send_email_tool_arguments",
+ "default": "send_email_tool_arguments",
+ "type": "string"
+ },
+ "sender_email": {
+ "format": "email",
+ "type": "string"
+ }
+ },
+ "required": [
+ "sender_email"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "limit": {
+ "default": 5,
+ "type": "integer"
+ },
+ "object": {
+ "const": "web_search_tool_arguments",
+ "default": "web_search_tool_arguments",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "object": {
+ "const": "web_page_reader_tool_arguments",
+ "default": "web_page_reader_tool_arguments",
+ "type": "string"
+ },
+ "target_selector": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Only returns elements from CSS selector."
+ },
+ "url": {
+ "type": "string"
+ },
+ "wait_for_selector": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Wait for a specific element to appear before returning. For dynamic content."
+ }
+ },
+ "required": [
+ "url"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "data_privacy_text": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional data privacy text. If provided, a checkbox should be displayed to the user."
+ },
+ "form_title": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "notification_email": {
+ "anyOf": [
+ {
+ "format": "email",
+ "type": "string"
+ },
+ {
+ "items": {
+ "format": "email",
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Used for email forwarding of form submissions. If not provided, no email will be forwarded"
+ },
+ "object": {
+ "const": "form_tool_arguments",
+ "default": "form_tool_arguments",
+ "type": "string"
+ },
+ "show_data_privacy_text": {
+ "default": false,
+ "type": "boolean"
+ },
+ "submit_button_text": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "submit_message": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "form_title",
+ "submit_message",
+ "submit_button_text"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "channels": {
+ "type": "string"
+ },
+ "domain": {
+ "type": "string"
+ },
+ "entity_type": {
+ "const": "Event",
+ "default": "Event",
+ "type": "string"
+ },
+ "event": {
+ "anyOf": [
+ {
+ "properties": {
+ "event_type": {
+ "enum": [
+ "carousel_v1"
+ ],
+ "type": "string"
+ },
+ "mapping": {
+ "properties": {
+ "detail": {
+ "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
+ "type": "string"
+ },
+ "id": {
+ "default": "{{event_id}}",
+ "type": "string"
+ },
+ "image_url": {
+ "default": "{{first_image.url}}",
+ "type": "string"
+ },
+ "resource_url": {
+ "default": "{{link}}",
+ "type": "string"
+ },
+ "tags": {
+ "default": "{{tags}}",
+ "type": "string"
+ },
+ "title": {
+ "default": "{{event_name}}",
+ "type": "string"
+ },
+ "type": {
+ "const": "carousel_v1",
+ "default": "carousel_v1",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "event_type",
+ "mapping"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional frontend event mapping."
+ },
+ "object": {
+ "const": "venus_knowledge_graph_tool_arguments",
+ "default": "venus_knowledge_graph_tool_arguments",
+ "type": "string"
+ },
+ "projects": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "projects",
+ "channels",
+ "domain"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "event": {
+ "anyOf": [
+ {
+ "properties": {
+ "event_type": {
+ "enum": [
+ "carousel_v1"
+ ],
+ "type": "string"
+ },
+ "mapping": {
+ "properties": {
+ "detail": {
+ "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
+ "type": "string"
+ },
+ "id": {
+ "default": "{{event_id}}",
+ "type": "string"
+ },
+ "image_url": {
+ "default": "{{first_image.url}}",
+ "type": "string"
+ },
+ "resource_url": {
+ "default": "{{link}}",
+ "type": "string"
+ },
+ "tags": {
+ "default": "{{tags}}",
+ "type": "string"
+ },
+ "title": {
+ "default": "{{event_name}}",
+ "type": "string"
+ },
+ "type": {
+ "const": "carousel_v1",
+ "default": "carousel_v1",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "event_type",
+ "mapping"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional frontend event mapping."
+ },
+ "object": {
+ "const": "regiondo_tool_arguments",
+ "default": "regiondo_tool_arguments",
+ "type": "string"
+ },
+ "public_key": {
+ "type": "string"
+ },
+ "secret_key": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "secret_key",
+ "public_key"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "events": {
+ "description": "List of frontend events to be triggered by this tool",
+ "items": {
+ "properties": {
+ "event_type": {
+ "enum": [
+ "carousel_v1"
+ ],
+ "type": "string"
+ },
+ "mapping": {
+ "properties": {
+ "detail": {
+ "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
+ "type": "string"
+ },
+ "id": {
+ "default": "{{event_id}}",
+ "type": "string"
+ },
+ "image_url": {
+ "default": "{{first_image.url}}",
+ "type": "string"
+ },
+ "resource_url": {
+ "default": "{{link}}",
+ "type": "string"
+ },
+ "tags": {
+ "default": "{{tags}}",
+ "type": "string"
+ },
+ "title": {
+ "default": "{{event_name}}",
+ "type": "string"
+ },
+ "type": {
+ "const": "carousel_v1",
+ "default": "carousel_v1",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "mcp_tool_entities": {
+ "anyOf": [
+ {
+ "properties": {
+ "key": {
+ "description": "The key to use to identify the entity from the MCP server response",
+ "type": "string"
+ },
+ "values": {
+ "description": "The specific entities (values) that should be mapped to the frontend event",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "key"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Mapping to distinguish entities from the MCP server response. If None, map to all entities"
+ },
+ "mcp_tool_names": {
+ "description": "List of tool names this frontend event should be mapped to. If empty, map to all tools of the MCP server.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "event_type",
+ "mapping"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "headers": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional headers to be sent with the request to the MCP server."
+ },
+ "image_url": {
+ "anyOf": [
+ {
+ "format": "uri",
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional image URL to be shown in the Dashboard. Only for frontend display."
+ },
+ "mcp_url": {
+ "format": "uri",
+ "minLength": 1,
+ "type": "string"
+ },
+ "object": {
+ "const": "mcp_server_tool_arguments",
+ "default": "mcp_server_tool_arguments",
+ "type": "string"
+ }
+ },
+ "required": [
+ "mcp_url"
+ ],
+ "type": "object"
+ },
+ {
+ "description": "Arguments for the API tool that define how to make HTTP requests.\n\nContains the static configuration for executing API requests.\nUse {{parameter_name}} mustache notation in url, query_params, headers, and body\nto reference parameters defined in tool_config.",
+ "properties": {
+ "body": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Request body. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
+ },
+ "body_content_type": {
+ "default": "application/json",
+ "description": "Content type of the request body.",
+ "enum": [
+ "application/json",
+ "application/x-www-form-urlencoded"
+ ],
+ "type": "string"
+ },
+ "event": {
+ "anyOf": [
+ {
+ "properties": {
+ "event_type": {
+ "enum": [
+ "carousel_v1"
+ ],
+ "type": "string"
+ },
+ "mapping": {
+ "properties": {
+ "detail": {
+ "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
+ "type": "string"
+ },
+ "id": {
+ "default": "{{event_id}}",
+ "type": "string"
+ },
+ "image_url": {
+ "default": "{{first_image.url}}",
+ "type": "string"
+ },
+ "resource_url": {
+ "default": "{{link}}",
+ "type": "string"
+ },
+ "tags": {
+ "default": "{{tags}}",
+ "type": "string"
+ },
+ "title": {
+ "default": "{{event_name}}",
+ "type": "string"
+ },
+ "type": {
+ "const": "carousel_v1",
+ "default": "carousel_v1",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "event_type",
+ "mapping"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional frontend event mapping."
+ },
+ "headers": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "HTTP headers for the request. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
+ },
+ "method": {
+ "description": "HTTP method for the API request.",
+ "enum": [
+ "GET",
+ "POST",
+ "PUT",
+ "PATCH",
+ "DELETE"
+ ],
+ "type": "string"
+ },
+ "object": {
+ "const": "api_tool_arguments",
+ "default": "api_tool_arguments",
+ "type": "string"
+ },
+ "query_params": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Query parameters for the request. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
+ },
+ "response_path": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional dot notation to extract specific data from the API response."
+ },
+ "timeout": {
+ "default": 5,
+ "description": "Request timeout in seconds.",
+ "maximum": 30,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "url": {
+ "description": "URL of the API endpoint. Can include parameter placeholders using mustache notation like {{parameter_name}}.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "method",
+ "url"
+ ],
+ "type": "object"
+ },
+ {
+ "description": "Arguments for the Buttons tool.\n\nThis tool allows AI to send buttons as a frontend event to users.\nNo inputs are required from the AI when executing this tool.\nMaximum 3 buttons can be sent.",
+ "properties": {
+ "buttons": {
+ "description": "List of buttons to display. Maximum 10 buttons.",
+ "items": {
+ "description": "Individual button in the buttons tool.\n\n- link_button: Opens URL in new tab (if external) or navigates (like follow-up actions)\n- button: Uses text as input for sending new request",
+ "properties": {
+ "text": {
+ "description": "Button text to display. Should be short and descriptive.",
+ "maxLength": 50,
+ "type": "string"
+ },
+ "type": {
+ "description": "Type of the button",
+ "enum": [
+ "link_button",
+ "button"
+ ],
+ "type": "string"
+ },
+ "url": {
+ "anyOf": [
+ {
+ "format": "uri",
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "URL for link_button type. Required for link_button, not used for button type. Allow mailto: and tel: links as well."
+ }
+ },
+ "required": [
+ "type",
+ "text"
+ ],
+ "type": "object"
+ },
+ "maxItems": 10,
+ "minItems": 1,
+ "type": "array"
+ },
+ "object": {
+ "const": "buttons_tool_arguments",
+ "default": "buttons_tool_arguments",
+ "type": "string"
+ }
+ },
+ "required": [
+ "buttons"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "default_travelmode": {
+ "anyOf": [
+ {
+ "enum": [
+ "driving",
+ "walking",
+ "bicycling",
+ "transit"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Default travel mode used when the AI does not specify one."
+ },
+ "icon_url": {
+ "anyOf": [
+ {
+ "format": "uri",
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional URL of an icon to display inside the link button."
+ },
+ "object": {
+ "const": "google_maps_link_tool_arguments",
+ "default": "google_maps_link_tool_arguments",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "default_mode": {
+ "anyOf": [
+ {
+ "enum": [
+ "driving",
+ "walking",
+ "bicycling",
+ "transit",
+ "flying"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Default travel mode used when the AI does not specify one."
+ },
+ "object": {
+ "const": "google_maps_embed_tool_arguments",
+ "default": "google_maps_embed_tool_arguments",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "integration_id": {
+ "description": "ID of the connected Calendly integration to use for scheduling.",
+ "format": "uuid",
+ "type": "string"
+ },
+ "object": {
+ "const": "calendly_tool_arguments",
+ "default": "calendly_tool_arguments",
+ "type": "string"
+ }
+ },
+ "required": [
+ "integration_id"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]update_tool1 field changedInput schema / properties / function_arguments / anyOfPrevious value: -[
- {
- "properties": {
- "data_source_ids_filter": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "data_source_types_filter": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "website_crawler",
- "file_upload",
- "node_editor",
- "default_node",
- "openAPI",
- "helpspace",
- "custom_website_crawler",
- "webhook",
- "wordpress"
- ],
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "document_limit_default": {
- "default": 15,
- "type": "integer"
- },
- "document_limit_rerank": {
- "default": 25,
- "type": "integer"
- },
- "formatter": {
- "default": "chunks_with_source",
- "enum": [
- "chunks_with_source",
- "numbered_chunks_with_source",
- "grouped_chunks",
- "grouped_chunks_with_custom_metadata",
- "grouped_chunks_with_page_metadata"
- ],
- "type": "string"
- },
- "node_ids_filter": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "node_labels_filter": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "entry",
- "content",
- "contact",
- "tool",
- "fallback",
- "integration",
- "style",
- "chat_navigator_style",
- "search_style",
- "search_result",
- "navigator",
- "feedback"
- ],
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "object": {
- "const": "knowledge_base_tool_arguments",
- "default": "knowledge_base_tool_arguments",
- "type": "string"
- },
- "rerank": {
- "default": false,
- "type": "boolean"
- },
- "retrieval_method": {
- "default": "default",
- "enum": [
- "default",
- "parent_context"
- ],
- "type": "string"
- },
- "sources_filter": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "node_ids": {
- "description": "List of node IDs to look up in the graph.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "object": {
- "const": "node_lookup_tool_arguments",
- "default": "node_lookup_tool_arguments",
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "object": {
- "const": "send_email_tool_arguments",
- "default": "send_email_tool_arguments",
- "type": "string"
- },
- "sender_email": {
- "format": "email",
- "type": "string"
- }
- },
- "required": [
- "sender_email"
- ],
- "type": "object"
- },
- {
- "properties": {
- "limit": {
- "default": 5,
- "type": "integer"
- },
- "object": {
- "const": "web_search_tool_arguments",
- "default": "web_search_tool_arguments",
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "object": {
- "const": "web_page_reader_tool_arguments",
- "default": "web_page_reader_tool_arguments",
- "type": "string"
- },
- "target_selector": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Only returns elements from CSS selector."
- },
- "url": {
- "type": "string"
- },
- "wait_for_selector": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Wait for a specific element to appear before returning. For dynamic content."
- }
- },
- "required": [
- "url"
- ],
- "type": "object"
- },
- {
- "properties": {
- "data_privacy_text": {
- "anyOf": [
- {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional data privacy text. If provided, a checkbox should be displayed to the user."
- },
- "form_title": {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- "notification_email": {
- "anyOf": [
- {
- "format": "email",
- "type": "string"
- },
- {
- "items": {
- "format": "email",
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Used for email forwarding of form submissions. If not provided, no email will be forwarded"
- },
- "object": {
- "const": "form_tool_arguments",
- "default": "form_tool_arguments",
- "type": "string"
- },
- "show_data_privacy_text": {
- "default": false,
- "type": "boolean"
- },
- "submit_button_text": {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- "submit_message": {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- }
- },
- "required": [
- "form_title",
- "submit_message",
- "submit_button_text"
- ],
- "type": "object"
- },
- {
- "properties": {
- "channels": {
- "type": "string"
- },
- "domain": {
- "type": "string"
- },
- "entity_type": {
- "const": "Event",
- "default": "Event",
- "type": "string"
- },
- "event": {
- "anyOf": [
- {
- "properties": {
- "event_type": {
- "enum": [
- "carousel_v1"
- ],
- "type": "string"
- },
- "mapping": {
- "properties": {
- "detail": {
- "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
- "type": "string"
- },
- "id": {
- "default": "{{event_id}}",
- "type": "string"
- },
- "image_url": {
- "default": "{{first_image.url}}",
- "type": "string"
- },
- "resource_url": {
- "default": "{{link}}",
- "type": "string"
- },
- "tags": {
- "default": "{{tags}}",
- "type": "string"
- },
- "title": {
- "default": "{{event_name}}",
- "type": "string"
- },
- "type": {
- "const": "carousel_v1",
- "default": "carousel_v1",
- "type": "string"
- }
- },
- "type": "object"
- }
- },
- "required": [
- "event_type",
- "mapping"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional frontend event mapping."
- },
- "object": {
- "const": "venus_knowledge_graph_tool_arguments",
- "default": "venus_knowledge_graph_tool_arguments",
- "type": "string"
- },
- "projects": {
- "type": "string"
- }
- },
- "required": [
- "projects",
- "channels",
- "domain"
- ],
- "type": "object"
- },
- {
- "properties": {
- "event": {
- "anyOf": [
- {
- "properties": {
- "event_type": {
- "enum": [
- "carousel_v1"
- ],
- "type": "string"
- },
- "mapping": {
- "properties": {
- "detail": {
- "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
- "type": "string"
- },
- "id": {
- "default": "{{event_id}}",
- "type": "string"
- },
- "image_url": {
- "default": "{{first_image.url}}",
- "type": "string"
- },
- "resource_url": {
- "default": "{{link}}",
- "type": "string"
- },
- "tags": {
- "default": "{{tags}}",
- "type": "string"
- },
- "title": {
- "default": "{{event_name}}",
- "type": "string"
- },
- "type": {
- "const": "carousel_v1",
- "default": "carousel_v1",
- "type": "string"
- }
- },
- "type": "object"
- }
- },
- "required": [
- "event_type",
- "mapping"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional frontend event mapping."
- },
- "object": {
- "const": "regiondo_tool_arguments",
- "default": "regiondo_tool_arguments",
- "type": "string"
- },
- "public_key": {
- "type": "string"
- },
- "secret_key": {
- "type": "string"
- }
- },
- "required": [
- "secret_key",
- "public_key"
- ],
- "type": "object"
- },
- {
- "properties": {
- "events": {
- "description": "List of frontend events to be triggered by this tool",
- "items": {
- "properties": {
- "event_type": {
- "enum": [
- "carousel_v1"
- ],
- "type": "string"
- },
- "mapping": {
- "properties": {
- "detail": {
- "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
- "type": "string"
- },
- "id": {
- "default": "{{event_id}}",
- "type": "string"
- },
- "image_url": {
- "default": "{{first_image.url}}",
- "type": "string"
- },
- "resource_url": {
- "default": "{{link}}",
- "type": "string"
- },
- "tags": {
- "default": "{{tags}}",
- "type": "string"
- },
- "title": {
- "default": "{{event_name}}",
- "type": "string"
- },
- "type": {
- "const": "carousel_v1",
- "default": "carousel_v1",
- "type": "string"
- }
- },
- "type": "object"
- },
- "mcp_tool_entities": {
- "anyOf": [
- {
- "properties": {
- "key": {
- "description": "The key to use to identify the entity from the MCP server response",
- "type": "string"
- },
- "values": {
- "description": "The specific entities (values) that should be mapped to the frontend event",
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "required": [
- "key"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Mapping to distinguish entities from the MCP server response. If None, map to all entities"
- },
- "mcp_tool_names": {
- "description": "List of tool names this frontend event should be mapped to. If empty, map to all tools of the MCP server.",
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "required": [
- "event_type",
- "mapping"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "headers": {
- "anyOf": [
- {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional headers to be sent with the request to the MCP server."
- },
- "image_url": {
- "anyOf": [
- {
- "format": "uri",
- "minLength": 1,
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional image URL to be shown in the Dashboard. Only for frontend display."
- },
- "mcp_url": {
- "format": "uri",
- "minLength": 1,
- "type": "string"
- },
- "object": {
- "const": "mcp_server_tool_arguments",
- "default": "mcp_server_tool_arguments",
- "type": "string"
- }
- },
- "required": [
- "mcp_url"
- ],
- "type": "object"
- },
- {
- "description": "Arguments for the API tool that define how to make HTTP requests.\n\nContains the static configuration for executing API requests.\nUse {{parameter_name}} mustache notation in url, query_params, headers, and body\nto reference parameters defined in tool_config.",
- "properties": {
- "body": {
- "anyOf": [
- {
- "additionalProperties": true,
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Request body. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
- },
- "body_content_type": {
- "default": "application/json",
- "description": "Content type of the request body.",
- "enum": [
- "application/json",
- "application/x-www-form-urlencoded"
- ],
- "type": "string"
- },
- "event": {
- "anyOf": [
- {
- "properties": {
- "event_type": {
- "enum": [
- "carousel_v1"
- ],
- "type": "string"
- },
- "mapping": {
- "properties": {
- "detail": {
- "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
- "type": "string"
- },
- "id": {
- "default": "{{event_id}}",
- "type": "string"
- },
- "image_url": {
- "default": "{{first_image.url}}",
- "type": "string"
- },
- "resource_url": {
- "default": "{{link}}",
- "type": "string"
- },
- "tags": {
- "default": "{{tags}}",
- "type": "string"
- },
- "title": {
- "default": "{{event_name}}",
- "type": "string"
- },
- "type": {
- "const": "carousel_v1",
- "default": "carousel_v1",
- "type": "string"
- }
- },
- "type": "object"
- }
- },
- "required": [
- "event_type",
- "mapping"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional frontend event mapping."
- },
- "headers": {
- "anyOf": [
- {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "HTTP headers for the request. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
- },
- "method": {
- "description": "HTTP method for the API request.",
- "enum": [
- "GET",
- "POST",
- "PUT",
- "PATCH",
- "DELETE"
- ],
- "type": "string"
- },
- "object": {
- "const": "api_tool_arguments",
- "default": "api_tool_arguments",
- "type": "string"
- },
- "query_params": {
- "anyOf": [
- {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Query parameters for the request. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
- },
- "response_path": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional dot notation to extract specific data from the API response."
- },
- "timeout": {
- "default": 5,
- "description": "Request timeout in seconds.",
- "maximum": 30,
- "minimum": 1,
- "type": "integer"
- },
- "url": {
- "description": "URL of the API endpoint. Can include parameter placeholders using mustache notation like {{parameter_name}}.",
- "type": "string"
- }
- },
- "required": [
- "method",
- "url"
- ],
- "type": "object"
- },
- {
- "description": "Arguments for the Buttons tool.\n\nThis tool allows AI to send buttons as a frontend event to users.\nNo inputs are required from the AI when executing this tool.\nMaximum 3 buttons can be sent.",
- "properties": {
- "buttons": {
- "description": "List of buttons to display. Maximum 10 buttons.",
- "items": {
- "description": "Individual button in the buttons tool.\n\n- link_button: Opens URL in new tab (if external) or navigates (like follow-up actions)\n- button: Uses text as input for sending new request",
- "properties": {
- "text": {
- "description": "Button text to display. Should be short and descriptive.",
- "maxLength": 50,
- "type": "string"
- },
- "type": {
- "description": "Type of the button",
- "enum": [
- "link_button",
- "button"
- ],
- "type": "string"
- },
- "url": {
- "anyOf": [
- {
- "format": "uri",
- "minLength": 1,
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "URL for link_button type. Required for link_button, not used for button type. Allow mailto: and tel: links as well."
- }
- },
- "required": [
- "type",
- "text"
- ],
- "type": "object"
- },
- "maxItems": 10,
- "minItems": 1,
- "type": "array"
- },
- "object": {
- "const": "buttons_tool_arguments",
- "default": "buttons_tool_arguments",
- "type": "string"
- }
- },
- "required": [
- "buttons"
- ],
- "type": "object"
- },
- {
- "properties": {
- "default_travelmode": {
- "anyOf": [
- {
- "enum": [
- "driving",
- "walking",
- "bicycling",
- "transit"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Default travel mode used when the AI does not specify one."
- },
- "icon_url": {
- "anyOf": [
- {
- "format": "uri",
- "minLength": 1,
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional URL of an icon to display inside the link button."
- },
- "object": {
- "const": "google_maps_link_tool_arguments",
- "default": "google_maps_link_tool_arguments",
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "default_mode": {
- "anyOf": [
- {
- "enum": [
- "driving",
- "walking",
- "bicycling",
- "transit",
- "flying"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Default travel mode used when the AI does not specify one."
- },
- "object": {
- "const": "google_maps_embed_tool_arguments",
- "default": "google_maps_embed_tool_arguments",
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "integration_id": {
- "description": "ID of the connected Calendly integration to use for scheduling.",
- "format": "uuid",
- "type": "string"
- },
- "object": {
- "const": "calendly_tool_arguments",
- "default": "calendly_tool_arguments",
- "type": "string"
- }
- },
- "required": [
- "integration_id"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "properties": {
+ "data_source_ids_filter": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "data_source_types_filter": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "website_crawler",
+ "file_upload",
+ "node_editor",
+ "default_node",
+ "openAPI",
+ "helpspace",
+ "custom_website_crawler",
+ "webhook",
+ "wordpress"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "document_limit_default": {
+ "default": 15,
+ "type": "integer"
+ },
+ "document_limit_rerank": {
+ "default": 25,
+ "type": "integer"
+ },
+ "formatter": {
+ "default": "chunks_with_source",
+ "enum": [
+ "chunks_with_source",
+ "numbered_chunks_with_source",
+ "grouped_chunks",
+ "grouped_chunks_with_custom_metadata",
+ "grouped_chunks_with_page_metadata"
+ ],
+ "type": "string"
+ },
+ "node_ids_filter": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "node_labels_filter": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "entry",
+ "content",
+ "contact",
+ "tool",
+ "fallback",
+ "integration",
+ "style",
+ "chat_navigator_style",
+ "search_style",
+ "search_result",
+ "navigator",
+ "feedback"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "object": {
+ "const": "knowledge_base_tool_arguments",
+ "default": "knowledge_base_tool_arguments",
+ "type": "string"
+ },
+ "rerank": {
+ "default": false,
+ "type": "boolean"
+ },
+ "retrieval_method": {
+ "default": "default",
+ "enum": [
+ "default",
+ "parent_context"
+ ],
+ "type": "string"
+ },
+ "sources_filter": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "node_ids": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "object": {
+ "const": "node_lookup_tool_arguments",
+ "default": "node_lookup_tool_arguments",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "object": {
+ "const": "send_email_tool_arguments",
+ "default": "send_email_tool_arguments",
+ "type": "string"
+ },
+ "sender_email": {
+ "format": "email",
+ "type": "string"
+ }
+ },
+ "required": [
+ "sender_email"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "limit": {
+ "default": 5,
+ "type": "integer"
+ },
+ "object": {
+ "const": "web_search_tool_arguments",
+ "default": "web_search_tool_arguments",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "object": {
+ "const": "web_page_reader_tool_arguments",
+ "default": "web_page_reader_tool_arguments",
+ "type": "string"
+ },
+ "target_selector": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Only returns elements from CSS selector."
+ },
+ "url": {
+ "type": "string"
+ },
+ "wait_for_selector": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Wait for a specific element to appear before returning. For dynamic content."
+ }
+ },
+ "required": [
+ "url"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "data_privacy_text": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional data privacy text. If provided, a checkbox should be displayed to the user."
+ },
+ "form_title": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "notification_email": {
+ "anyOf": [
+ {
+ "format": "email",
+ "type": "string"
+ },
+ {
+ "items": {
+ "format": "email",
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Used for email forwarding of form submissions. If not provided, no email will be forwarded"
+ },
+ "object": {
+ "const": "form_tool_arguments",
+ "default": "form_tool_arguments",
+ "type": "string"
+ },
+ "show_data_privacy_text": {
+ "default": false,
+ "type": "boolean"
+ },
+ "submit_button_text": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "submit_message": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "form_title",
+ "submit_message",
+ "submit_button_text"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "channels": {
+ "type": "string"
+ },
+ "domain": {
+ "type": "string"
+ },
+ "entity_type": {
+ "const": "Event",
+ "default": "Event",
+ "type": "string"
+ },
+ "event": {
+ "anyOf": [
+ {
+ "properties": {
+ "event_type": {
+ "enum": [
+ "carousel_v1"
+ ],
+ "type": "string"
+ },
+ "mapping": {
+ "properties": {
+ "detail": {
+ "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
+ "type": "string"
+ },
+ "id": {
+ "default": "{{event_id}}",
+ "type": "string"
+ },
+ "image_url": {
+ "default": "{{first_image.url}}",
+ "type": "string"
+ },
+ "resource_url": {
+ "default": "{{link}}",
+ "type": "string"
+ },
+ "tags": {
+ "default": "{{tags}}",
+ "type": "string"
+ },
+ "title": {
+ "default": "{{event_name}}",
+ "type": "string"
+ },
+ "type": {
+ "const": "carousel_v1",
+ "default": "carousel_v1",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "event_type",
+ "mapping"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional frontend event mapping."
+ },
+ "object": {
+ "const": "venus_knowledge_graph_tool_arguments",
+ "default": "venus_knowledge_graph_tool_arguments",
+ "type": "string"
+ },
+ "projects": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "projects",
+ "channels",
+ "domain"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "event": {
+ "anyOf": [
+ {
+ "properties": {
+ "event_type": {
+ "enum": [
+ "carousel_v1"
+ ],
+ "type": "string"
+ },
+ "mapping": {
+ "properties": {
+ "detail": {
+ "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
+ "type": "string"
+ },
+ "id": {
+ "default": "{{event_id}}",
+ "type": "string"
+ },
+ "image_url": {
+ "default": "{{first_image.url}}",
+ "type": "string"
+ },
+ "resource_url": {
+ "default": "{{link}}",
+ "type": "string"
+ },
+ "tags": {
+ "default": "{{tags}}",
+ "type": "string"
+ },
+ "title": {
+ "default": "{{event_name}}",
+ "type": "string"
+ },
+ "type": {
+ "const": "carousel_v1",
+ "default": "carousel_v1",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "event_type",
+ "mapping"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional frontend event mapping."
+ },
+ "object": {
+ "const": "regiondo_tool_arguments",
+ "default": "regiondo_tool_arguments",
+ "type": "string"
+ },
+ "public_key": {
+ "type": "string"
+ },
+ "secret_key": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "secret_key",
+ "public_key"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "events": {
+ "description": "List of frontend events to be triggered by this tool",
+ "items": {
+ "properties": {
+ "event_type": {
+ "enum": [
+ "carousel_v1"
+ ],
+ "type": "string"
+ },
+ "mapping": {
+ "properties": {
+ "detail": {
+ "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
+ "type": "string"
+ },
+ "id": {
+ "default": "{{event_id}}",
+ "type": "string"
+ },
+ "image_url": {
+ "default": "{{first_image.url}}",
+ "type": "string"
+ },
+ "resource_url": {
+ "default": "{{link}}",
+ "type": "string"
+ },
+ "tags": {
+ "default": "{{tags}}",
+ "type": "string"
+ },
+ "title": {
+ "default": "{{event_name}}",
+ "type": "string"
+ },
+ "type": {
+ "const": "carousel_v1",
+ "default": "carousel_v1",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "mcp_tool_entities": {
+ "anyOf": [
+ {
+ "properties": {
+ "key": {
+ "description": "The key to use to identify the entity from the MCP server response",
+ "type": "string"
+ },
+ "values": {
+ "description": "The specific entities (values) that should be mapped to the frontend event",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "key"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Mapping to distinguish entities from the MCP server response. If None, map to all entities"
+ },
+ "mcp_tool_names": {
+ "description": "List of tool names this frontend event should be mapped to. If empty, map to all tools of the MCP server.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "event_type",
+ "mapping",
+ "mcp_tool_entities"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "headers": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional headers to be sent with the request to the MCP server."
+ },
+ "image_url": {
+ "anyOf": [
+ {
+ "format": "uri",
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional image URL to be shown in the Dashboard. Only for frontend display."
+ },
+ "mcp_url": {
+ "format": "uri",
+ "minLength": 1,
+ "type": "string"
+ },
+ "object": {
+ "const": "mcp_server_tool_arguments",
+ "default": "mcp_server_tool_arguments",
+ "type": "string"
+ }
+ },
+ "required": [
+ "mcp_url"
+ ],
+ "type": "object"
+ },
+ {
+ "description": "Arguments for the API tool that define how to make HTTP requests.\n\nContains the static configuration for executing API requests.\nUse {{parameter_name}} mustache notation in url, query_params, headers, and body\nto reference parameters defined in tool_config.",
+ "properties": {
+ "body": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Request body. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
+ },
+ "body_content_type": {
+ "default": "application/json",
+ "description": "Content type of the request body.",
+ "enum": [
+ "application/json",
+ "application/x-www-form-urlencoded"
+ ],
+ "type": "string"
+ },
+ "event": {
+ "anyOf": [
+ {
+ "properties": {
+ "event_type": {
+ "enum": [
+ "carousel_v1"
+ ],
+ "type": "string"
+ },
+ "mapping": {
+ "properties": {
+ "detail": {
+ "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
+ "type": "string"
+ },
+ "id": {
+ "default": "{{event_id}}",
+ "type": "string"
+ },
+ "image_url": {
+ "default": "{{first_image.url}}",
+ "type": "string"
+ },
+ "resource_url": {
+ "default": "{{link}}",
+ "type": "string"
+ },
+ "tags": {
+ "default": "{{tags}}",
+ "type": "string"
+ },
+ "title": {
+ "default": "{{event_name}}",
+ "type": "string"
+ },
+ "type": {
+ "const": "carousel_v1",
+ "default": "carousel_v1",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "event_type",
+ "mapping"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional frontend event mapping."
+ },
+ "headers": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "HTTP headers for the request. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
+ },
+ "method": {
+ "description": "HTTP method for the API request.",
+ "enum": [
+ "GET",
+ "POST",
+ "PUT",
+ "PATCH",
+ "DELETE"
+ ],
+ "type": "string"
+ },
+ "object": {
+ "const": "api_tool_arguments",
+ "default": "api_tool_arguments",
+ "type": "string"
+ },
+ "query_params": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Query parameters for the request. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
+ },
+ "response_path": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional dot notation to extract specific data from the API response."
+ },
+ "timeout": {
+ "default": 5,
+ "description": "Request timeout in seconds.",
+ "maximum": 30,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "url": {
+ "description": "URL of the API endpoint. Can include parameter placeholders using mustache notation like {{parameter_name}}.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "method",
+ "url"
+ ],
+ "type": "object"
+ },
+ {
+ "description": "Arguments for the Buttons tool.\n\nThis tool allows AI to send buttons as a frontend event to users.\nNo inputs are required from the AI when executing this tool.\nMaximum 3 buttons can be sent.",
+ "properties": {
+ "buttons": {
+ "description": "List of buttons to display. Maximum 10 buttons.",
+ "items": {
+ "description": "Individual button in the buttons tool.\n\n- link_button: Opens URL in new tab (if external) or navigates (like follow-up actions)\n- button: Uses text as input for sending new request",
+ "properties": {
+ "text": {
+ "description": "Button text to display. Should be short and descriptive.",
+ "maxLength": 50,
+ "type": "string"
+ },
+ "type": {
+ "description": "Type of the button",
+ "enum": [
+ "link_button",
+ "button"
+ ],
+ "type": "string"
+ },
+ "url": {
+ "anyOf": [
+ {
+ "format": "uri",
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "URL for link_button type. Required for link_button, not used for button type. Allow mailto: and tel: links as well."
+ }
+ },
+ "required": [
+ "type",
+ "text"
+ ],
+ "type": "object"
+ },
+ "maxItems": 10,
+ "minItems": 1,
+ "type": "array"
+ },
+ "object": {
+ "const": "buttons_tool_arguments",
+ "default": "buttons_tool_arguments",
+ "type": "string"
+ }
+ },
+ "required": [
+ "buttons"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "default_travelmode": {
+ "anyOf": [
+ {
+ "enum": [
+ "driving",
+ "walking",
+ "bicycling",
+ "transit"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Default travel mode used when the AI does not specify one."
+ },
+ "icon_url": {
+ "anyOf": [
+ {
+ "format": "uri",
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional URL of an icon to display inside the link button."
+ },
+ "object": {
+ "const": "google_maps_link_tool_arguments",
+ "default": "google_maps_link_tool_arguments",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "default_mode": {
+ "anyOf": [
+ {
+ "enum": [
+ "driving",
+ "walking",
+ "bicycling",
+ "transit",
+ "flying"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Default travel mode used when the AI does not specify one."
+ },
+ "object": {
+ "const": "google_maps_embed_tool_arguments",
+ "default": "google_maps_embed_tool_arguments",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "integration_id": {
+ "description": "ID of the connected Calendly integration to use for scheduling.",
+ "format": "uuid",
+ "type": "string"
+ },
+ "object": {
+ "const": "calendly_tool_arguments",
+ "default": "calendly_tool_arguments",
+ "type": "string"
+ }
+ },
+ "required": [
+ "integration_id"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]update_tool1 field changedInput schema / properties / function_arguments / anyOfPrevious value: -[
- {
- "properties": {
- "data_source_ids_filter": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "data_source_types_filter": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "website_crawler",
- "file_upload",
- "node_editor",
- "default_node",
- "openAPI",
- "helpspace",
- "custom_website_crawler",
- "webhook",
- "wordpress"
- ],
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "document_limit_default": {
- "default": 15,
- "type": "integer"
- },
- "document_limit_rerank": {
- "default": 25,
- "type": "integer"
- },
- "formatter": {
- "default": "chunks_with_source",
- "enum": [
- "chunks_with_source",
- "numbered_chunks_with_source",
- "grouped_chunks",
- "grouped_chunks_with_custom_metadata",
- "grouped_chunks_with_page_metadata"
- ],
- "type": "string"
- },
- "node_ids_filter": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "node_labels_filter": {
- "anyOf": [
- {
- "items": {
- "enum": [
- "entry",
- "content",
- "contact",
- "tool",
- "fallback",
- "integration",
- "style",
- "chat_navigator_style",
- "search_style",
- "search_result",
- "navigator",
- "feedback"
- ],
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- },
- "object": {
- "const": "knowledge_base_tool_arguments",
- "default": "knowledge_base_tool_arguments",
- "type": "string"
- },
- "rerank": {
- "default": false,
- "type": "boolean"
- },
- "retrieval_method": {
- "default": "default",
- "enum": [
- "default",
- "parent_context"
- ],
- "type": "string"
- },
- "sources_filter": {
- "anyOf": [
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "node_ids": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "object": {
- "const": "node_lookup_tool_arguments",
- "default": "node_lookup_tool_arguments",
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "object": {
- "const": "send_email_tool_arguments",
- "default": "send_email_tool_arguments",
- "type": "string"
- },
- "sender_email": {
- "format": "email",
- "type": "string"
- }
- },
- "required": [
- "sender_email"
- ],
- "type": "object"
- },
- {
- "properties": {
- "limit": {
- "default": 5,
- "type": "integer"
- },
- "object": {
- "const": "web_search_tool_arguments",
- "default": "web_search_tool_arguments",
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "object": {
- "const": "web_page_reader_tool_arguments",
- "default": "web_page_reader_tool_arguments",
- "type": "string"
- },
- "target_selector": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Only returns elements from CSS selector."
- },
- "url": {
- "type": "string"
- },
- "wait_for_selector": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Wait for a specific element to appear before returning. For dynamic content."
- }
- },
- "required": [
- "url"
- ],
- "type": "object"
- },
- {
- "properties": {
- "data_privacy_text": {
- "anyOf": [
- {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional data privacy text. If provided, a checkbox should be displayed to the user."
- },
- "form_title": {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- "notification_email": {
- "anyOf": [
- {
- "format": "email",
- "type": "string"
- },
- {
- "items": {
- "format": "email",
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Used for email forwarding of form submissions. If not provided, no email will be forwarded"
- },
- "object": {
- "const": "form_tool_arguments",
- "default": "form_tool_arguments",
- "type": "string"
- },
- "show_data_privacy_text": {
- "default": false,
- "type": "boolean"
- },
- "submit_button_text": {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- "submit_message": {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- }
- },
- "required": [
- "form_title",
- "submit_message",
- "submit_button_text"
- ],
- "type": "object"
- },
- {
- "properties": {
- "channels": {
- "type": "string"
- },
- "domain": {
- "type": "string"
- },
- "entity_type": {
- "const": "Event",
- "default": "Event",
- "type": "string"
- },
- "event": {
- "anyOf": [
- {
- "properties": {
- "event_type": {
- "enum": [
- "carousel_v1"
- ],
- "type": "string"
- },
- "mapping": {
- "properties": {
- "detail": {
- "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
- "type": "string"
- },
- "id": {
- "default": "{{event_id}}",
- "type": "string"
- },
- "image_url": {
- "default": "{{first_image.url}}",
- "type": "string"
- },
- "resource_url": {
- "default": "{{link}}",
- "type": "string"
- },
- "tags": {
- "default": "{{tags}}",
- "type": "string"
- },
- "title": {
- "default": "{{event_name}}",
- "type": "string"
- },
- "type": {
- "const": "carousel_v1",
- "default": "carousel_v1",
- "type": "string"
- }
- },
- "type": "object"
- }
- },
- "required": [
- "event_type",
- "mapping"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional frontend event mapping."
- },
- "object": {
- "const": "venus_knowledge_graph_tool_arguments",
- "default": "venus_knowledge_graph_tool_arguments",
- "type": "string"
- },
- "projects": {
- "type": "string"
- }
- },
- "required": [
- "projects",
- "channels",
- "domain"
- ],
- "type": "object"
- },
- {
- "properties": {
- "event": {
- "anyOf": [
- {
- "properties": {
- "event_type": {
- "enum": [
- "carousel_v1"
- ],
- "type": "string"
- },
- "mapping": {
- "properties": {
- "detail": {
- "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
- "type": "string"
- },
- "id": {
- "default": "{{event_id}}",
- "type": "string"
- },
- "image_url": {
- "default": "{{first_image.url}}",
- "type": "string"
- },
- "resource_url": {
- "default": "{{link}}",
- "type": "string"
- },
- "tags": {
- "default": "{{tags}}",
- "type": "string"
- },
- "title": {
- "default": "{{event_name}}",
- "type": "string"
- },
- "type": {
- "const": "carousel_v1",
- "default": "carousel_v1",
- "type": "string"
- }
- },
- "type": "object"
- }
- },
- "required": [
- "event_type",
- "mapping"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional frontend event mapping."
- },
- "object": {
- "const": "regiondo_tool_arguments",
- "default": "regiondo_tool_arguments",
- "type": "string"
- },
- "public_key": {
- "type": "string"
- },
- "secret_key": {
- "type": "string"
- }
- },
- "required": [
- "secret_key",
- "public_key"
- ],
- "type": "object"
- },
- {
- "properties": {
- "events": {
- "description": "List of frontend events to be triggered by this tool",
- "items": {
- "properties": {
- "event_type": {
- "enum": [
- "carousel_v1"
- ],
- "type": "string"
- },
- "mapping": {
- "properties": {
- "detail": {
- "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
- "type": "string"
- },
- "id": {
- "default": "{{event_id}}",
- "type": "string"
- },
- "image_url": {
- "default": "{{first_image.url}}",
- "type": "string"
- },
- "resource_url": {
- "default": "{{link}}",
- "type": "string"
- },
- "tags": {
- "default": "{{tags}}",
- "type": "string"
- },
- "title": {
- "default": "{{event_name}}",
- "type": "string"
- },
- "type": {
- "const": "carousel_v1",
- "default": "carousel_v1",
- "type": "string"
- }
- },
- "type": "object"
- },
- "mcp_tool_entities": {
- "anyOf": [
- {
- "properties": {
- "key": {
- "description": "The key to use to identify the entity from the MCP server response",
- "type": "string"
- },
- "values": {
- "description": "The specific entities (values) that should be mapped to the frontend event",
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "required": [
- "key"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "description": "Mapping to distinguish entities from the MCP server response. If None, map to all entities"
- },
- "mcp_tool_names": {
- "description": "List of tool names this frontend event should be mapped to. If empty, map to all tools of the MCP server.",
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "required": [
- "event_type",
- "mapping",
- "mcp_tool_entities"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "headers": {
- "anyOf": [
- {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional headers to be sent with the request to the MCP server."
- },
- "image_url": {
- "anyOf": [
- {
- "format": "uri",
- "minLength": 1,
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional image URL to be shown in the Dashboard. Only for frontend display."
- },
- "mcp_url": {
- "format": "uri",
- "minLength": 1,
- "type": "string"
- },
- "object": {
- "const": "mcp_server_tool_arguments",
- "default": "mcp_server_tool_arguments",
- "type": "string"
- }
- },
- "required": [
- "mcp_url"
- ],
- "type": "object"
- },
- {
- "description": "Arguments for the API tool that define how to make HTTP requests.\n\nContains the static configuration for executing API requests.\nUse {{parameter_name}} mustache notation in url, query_params, headers, and body\nto reference parameters defined in tool_config.",
- "properties": {
- "body": {
- "anyOf": [
- {
- "additionalProperties": true,
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Request body. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
- },
- "body_content_type": {
- "default": "application/json",
- "description": "Content type of the request body.",
- "enum": [
- "application/json",
- "application/x-www-form-urlencoded"
- ],
- "type": "string"
- },
- "event": {
- "anyOf": [
- {
- "properties": {
- "event_type": {
- "enum": [
- "carousel_v1"
- ],
- "type": "string"
- },
- "mapping": {
- "properties": {
- "detail": {
- "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
- "type": "string"
- },
- "id": {
- "default": "{{event_id}}",
- "type": "string"
- },
- "image_url": {
- "default": "{{first_image.url}}",
- "type": "string"
- },
- "resource_url": {
- "default": "{{link}}",
- "type": "string"
- },
- "tags": {
- "default": "{{tags}}",
- "type": "string"
- },
- "title": {
- "default": "{{event_name}}",
- "type": "string"
- },
- "type": {
- "const": "carousel_v1",
- "default": "carousel_v1",
- "type": "string"
- }
- },
- "type": "object"
- }
- },
- "required": [
- "event_type",
- "mapping"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional frontend event mapping."
- },
- "headers": {
- "anyOf": [
- {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "HTTP headers for the request. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
- },
- "method": {
- "description": "HTTP method for the API request.",
- "enum": [
- "GET",
- "POST",
- "PUT",
- "PATCH",
- "DELETE"
- ],
- "type": "string"
- },
- "object": {
- "const": "api_tool_arguments",
- "default": "api_tool_arguments",
- "type": "string"
- },
- "query_params": {
- "anyOf": [
- {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Query parameters for the request. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
- },
- "response_path": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional dot notation to extract specific data from the API response."
- },
- "timeout": {
- "default": 5,
- "description": "Request timeout in seconds.",
- "maximum": 30,
- "minimum": 1,
- "type": "integer"
- },
- "url": {
- "description": "URL of the API endpoint. Can include parameter placeholders using mustache notation like {{parameter_name}}.",
- "type": "string"
- }
- },
- "required": [
- "method",
- "url"
- ],
- "type": "object"
- },
- {
- "description": "Arguments for the Buttons tool.\n\nThis tool allows AI to send buttons as a frontend event to users.\nNo inputs are required from the AI when executing this tool.\nMaximum 3 buttons can be sent.",
- "properties": {
- "buttons": {
- "description": "List of buttons to display. Maximum 10 buttons.",
- "items": {
- "description": "Individual button in the buttons tool.\n\n- link_button: Opens URL in new tab (if external) or navigates (like follow-up actions)\n- button: Uses text as input for sending new request",
- "properties": {
- "text": {
- "description": "Button text to display. Should be short and descriptive.",
- "maxLength": 50,
- "type": "string"
- },
- "type": {
- "description": "Type of the button",
- "enum": [
- "link_button",
- "button"
- ],
- "type": "string"
- },
- "url": {
- "anyOf": [
- {
- "format": "uri",
- "minLength": 1,
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "URL for link_button type. Required for link_button, not used for button type. Allow mailto: and tel: links as well."
- }
- },
- "required": [
- "type",
- "text"
- ],
- "type": "object"
- },
- "maxItems": 10,
- "minItems": 1,
- "type": "array"
- },
- "object": {
- "const": "buttons_tool_arguments",
- "default": "buttons_tool_arguments",
- "type": "string"
- }
- },
- "required": [
- "buttons"
- ],
- "type": "object"
- },
- {
- "properties": {
- "default_travelmode": {
- "anyOf": [
- {
- "enum": [
- "driving",
- "walking",
- "bicycling",
- "transit"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Default travel mode used when the AI does not specify one."
- },
- "icon_url": {
- "anyOf": [
- {
- "format": "uri",
- "minLength": 1,
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional URL of an icon to display inside the link button."
- },
- "object": {
- "const": "google_maps_link_tool_arguments",
- "default": "google_maps_link_tool_arguments",
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "default_mode": {
- "anyOf": [
- {
- "enum": [
- "driving",
- "walking",
- "bicycling",
- "transit",
- "flying"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Default travel mode used when the AI does not specify one."
- },
- "object": {
- "const": "google_maps_embed_tool_arguments",
- "default": "google_maps_embed_tool_arguments",
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "integration_id": {
- "description": "ID of the connected Calendly integration to use for scheduling.",
- "format": "uuid",
- "type": "string"
- },
- "object": {
- "const": "calendly_tool_arguments",
- "default": "calendly_tool_arguments",
- "type": "string"
- }
- },
- "required": [
- "integration_id"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "properties": {
+ "data_source_ids_filter": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "data_source_types_filter": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "website_crawler",
+ "file_upload",
+ "node_editor",
+ "default_node",
+ "openAPI",
+ "helpspace",
+ "custom_website_crawler",
+ "webhook",
+ "wordpress"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "document_limit_default": {
+ "default": 15,
+ "type": "integer"
+ },
+ "document_limit_rerank": {
+ "default": 25,
+ "type": "integer"
+ },
+ "formatter": {
+ "default": "chunks_with_source",
+ "enum": [
+ "chunks_with_source",
+ "numbered_chunks_with_source",
+ "grouped_chunks",
+ "grouped_chunks_with_custom_metadata",
+ "grouped_chunks_with_page_metadata"
+ ],
+ "type": "string"
+ },
+ "node_ids_filter": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "node_labels_filter": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "entry",
+ "content",
+ "contact",
+ "tool",
+ "fallback",
+ "integration",
+ "style",
+ "chat_navigator_style",
+ "search_style",
+ "search_result",
+ "navigator",
+ "feedback"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "object": {
+ "const": "knowledge_base_tool_arguments",
+ "default": "knowledge_base_tool_arguments",
+ "type": "string"
+ },
+ "rerank": {
+ "default": false,
+ "type": "boolean"
+ },
+ "retrieval_method": {
+ "default": "default",
+ "enum": [
+ "default",
+ "parent_context"
+ ],
+ "type": "string"
+ },
+ "sources_filter": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "node_ids": {
+ "description": "List of node IDs to look up in the graph.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "object": {
+ "const": "node_lookup_tool_arguments",
+ "default": "node_lookup_tool_arguments",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "object": {
+ "const": "send_email_tool_arguments",
+ "default": "send_email_tool_arguments",
+ "type": "string"
+ },
+ "sender_email": {
+ "format": "email",
+ "type": "string"
+ }
+ },
+ "required": [
+ "sender_email"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "limit": {
+ "default": 5,
+ "type": "integer"
+ },
+ "object": {
+ "const": "web_search_tool_arguments",
+ "default": "web_search_tool_arguments",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "object": {
+ "const": "web_page_reader_tool_arguments",
+ "default": "web_page_reader_tool_arguments",
+ "type": "string"
+ },
+ "target_selector": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Only returns elements from CSS selector."
+ },
+ "url": {
+ "type": "string"
+ },
+ "wait_for_selector": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Wait for a specific element to appear before returning. For dynamic content."
+ }
+ },
+ "required": [
+ "url"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "data_privacy_text": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional data privacy text. If provided, a checkbox should be displayed to the user."
+ },
+ "form_title": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "notification_email": {
+ "anyOf": [
+ {
+ "format": "email",
+ "type": "string"
+ },
+ {
+ "items": {
+ "format": "email",
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Used for email forwarding of form submissions. If not provided, no email will be forwarded"
+ },
+ "object": {
+ "const": "form_tool_arguments",
+ "default": "form_tool_arguments",
+ "type": "string"
+ },
+ "show_data_privacy_text": {
+ "default": false,
+ "type": "boolean"
+ },
+ "submit_button_text": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "submit_message": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "form_title",
+ "submit_message",
+ "submit_button_text"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "channels": {
+ "type": "string"
+ },
+ "domain": {
+ "type": "string"
+ },
+ "entity_type": {
+ "const": "Event",
+ "default": "Event",
+ "type": "string"
+ },
+ "event": {
+ "anyOf": [
+ {
+ "properties": {
+ "event_type": {
+ "enum": [
+ "carousel_v1"
+ ],
+ "type": "string"
+ },
+ "mapping": {
+ "properties": {
+ "detail": {
+ "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
+ "type": "string"
+ },
+ "id": {
+ "default": "{{event_id}}",
+ "type": "string"
+ },
+ "image_url": {
+ "default": "{{first_image.url}}",
+ "type": "string"
+ },
+ "resource_url": {
+ "default": "{{link}}",
+ "type": "string"
+ },
+ "tags": {
+ "default": "{{tags}}",
+ "type": "string"
+ },
+ "title": {
+ "default": "{{event_name}}",
+ "type": "string"
+ },
+ "type": {
+ "const": "carousel_v1",
+ "default": "carousel_v1",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "event_type",
+ "mapping"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional frontend event mapping."
+ },
+ "object": {
+ "const": "venus_knowledge_graph_tool_arguments",
+ "default": "venus_knowledge_graph_tool_arguments",
+ "type": "string"
+ },
+ "projects": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "projects",
+ "channels",
+ "domain"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "event": {
+ "anyOf": [
+ {
+ "properties": {
+ "event_type": {
+ "enum": [
+ "carousel_v1"
+ ],
+ "type": "string"
+ },
+ "mapping": {
+ "properties": {
+ "detail": {
+ "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
+ "type": "string"
+ },
+ "id": {
+ "default": "{{event_id}}",
+ "type": "string"
+ },
+ "image_url": {
+ "default": "{{first_image.url}}",
+ "type": "string"
+ },
+ "resource_url": {
+ "default": "{{link}}",
+ "type": "string"
+ },
+ "tags": {
+ "default": "{{tags}}",
+ "type": "string"
+ },
+ "title": {
+ "default": "{{event_name}}",
+ "type": "string"
+ },
+ "type": {
+ "const": "carousel_v1",
+ "default": "carousel_v1",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "event_type",
+ "mapping"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional frontend event mapping."
+ },
+ "object": {
+ "const": "regiondo_tool_arguments",
+ "default": "regiondo_tool_arguments",
+ "type": "string"
+ },
+ "public_key": {
+ "type": "string"
+ },
+ "secret_key": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "secret_key",
+ "public_key"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "events": {
+ "description": "List of frontend events to be triggered by this tool",
+ "items": {
+ "properties": {
+ "event_type": {
+ "enum": [
+ "carousel_v1"
+ ],
+ "type": "string"
+ },
+ "mapping": {
+ "properties": {
+ "detail": {
+ "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
+ "type": "string"
+ },
+ "id": {
+ "default": "{{event_id}}",
+ "type": "string"
+ },
+ "image_url": {
+ "default": "{{first_image.url}}",
+ "type": "string"
+ },
+ "resource_url": {
+ "default": "{{link}}",
+ "type": "string"
+ },
+ "tags": {
+ "default": "{{tags}}",
+ "type": "string"
+ },
+ "title": {
+ "default": "{{event_name}}",
+ "type": "string"
+ },
+ "type": {
+ "const": "carousel_v1",
+ "default": "carousel_v1",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "mcp_tool_entities": {
+ "anyOf": [
+ {
+ "properties": {
+ "key": {
+ "description": "The key to use to identify the entity from the MCP server response",
+ "type": "string"
+ },
+ "values": {
+ "description": "The specific entities (values) that should be mapped to the frontend event",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "key"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Mapping to distinguish entities from the MCP server response. If None, map to all entities"
+ },
+ "mcp_tool_names": {
+ "description": "List of tool names this frontend event should be mapped to. If empty, map to all tools of the MCP server.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "event_type",
+ "mapping"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "headers": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional headers to be sent with the request to the MCP server."
+ },
+ "image_url": {
+ "anyOf": [
+ {
+ "format": "uri",
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional image URL to be shown in the Dashboard. Only for frontend display."
+ },
+ "mcp_url": {
+ "format": "uri",
+ "minLength": 1,
+ "type": "string"
+ },
+ "object": {
+ "const": "mcp_server_tool_arguments",
+ "default": "mcp_server_tool_arguments",
+ "type": "string"
+ }
+ },
+ "required": [
+ "mcp_url"
+ ],
+ "type": "object"
+ },
+ {
+ "description": "Arguments for the API tool that define how to make HTTP requests.\n\nContains the static configuration for executing API requests.\nUse {{parameter_name}} mustache notation in url, query_params, headers, and body\nto reference parameters defined in tool_config.",
+ "properties": {
+ "body": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Request body. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
+ },
+ "body_content_type": {
+ "default": "application/json",
+ "description": "Content type of the request body.",
+ "enum": [
+ "application/json",
+ "application/x-www-form-urlencoded"
+ ],
+ "type": "string"
+ },
+ "event": {
+ "anyOf": [
+ {
+ "properties": {
+ "event_type": {
+ "enum": [
+ "carousel_v1"
+ ],
+ "type": "string"
+ },
+ "mapping": {
+ "properties": {
+ "detail": {
+ "default": "{{event_date_time.0.start_date}} - {{event_date_time.0.end_date}}<br>{{address.city}}<br>",
+ "type": "string"
+ },
+ "id": {
+ "default": "{{event_id}}",
+ "type": "string"
+ },
+ "image_url": {
+ "default": "{{first_image.url}}",
+ "type": "string"
+ },
+ "resource_url": {
+ "default": "{{link}}",
+ "type": "string"
+ },
+ "tags": {
+ "default": "{{tags}}",
+ "type": "string"
+ },
+ "title": {
+ "default": "{{event_name}}",
+ "type": "string"
+ },
+ "type": {
+ "const": "carousel_v1",
+ "default": "carousel_v1",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "event_type",
+ "mapping"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional frontend event mapping."
+ },
+ "headers": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "HTTP headers for the request. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
+ },
+ "method": {
+ "description": "HTTP method for the API request.",
+ "enum": [
+ "GET",
+ "POST",
+ "PUT",
+ "PATCH",
+ "DELETE"
+ ],
+ "type": "string"
+ },
+ "object": {
+ "const": "api_tool_arguments",
+ "default": "api_tool_arguments",
+ "type": "string"
+ },
+ "query_params": {
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Query parameters for the request. Values can include parameter placeholders using mustache notation like {{parameter_name}}."
+ },
+ "response_path": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional dot notation to extract specific data from the API response."
+ },
+ "timeout": {
+ "default": 5,
+ "description": "Request timeout in seconds.",
+ "maximum": 30,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "url": {
+ "description": "URL of the API endpoint. Can include parameter placeholders using mustache notation like {{parameter_name}}.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "method",
+ "url"
+ ],
+ "type": "object"
+ },
+ {
+ "description": "Arguments for the Buttons tool.\n\nThis tool allows AI to send buttons as a frontend event to users.\nNo inputs are required from the AI when executing this tool.\nMaximum 3 buttons can be sent.",
+ "properties": {
+ "buttons": {
+ "description": "List of buttons to display. Maximum 10 buttons.",
+ "items": {
+ "description": "Individual button in the buttons tool.\n\n- link_button: Opens URL in new tab (if external) or navigates (like follow-up actions)\n- button: Uses text as input for sending new request",
+ "properties": {
+ "text": {
+ "description": "Button text to display. Should be short and descriptive.",
+ "maxLength": 50,
+ "type": "string"
+ },
+ "type": {
+ "description": "Type of the button",
+ "enum": [
+ "link_button",
+ "button"
+ ],
+ "type": "string"
+ },
+ "url": {
+ "anyOf": [
+ {
+ "format": "uri",
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "URL for link_button type. Required for link_button, not used for button type. Allow mailto: and tel: links as well."
+ }
+ },
+ "required": [
+ "type",
+ "text"
+ ],
+ "type": "object"
+ },
+ "maxItems": 10,
+ "minItems": 1,
+ "type": "array"
+ },
+ "object": {
+ "const": "buttons_tool_arguments",
+ "default": "buttons_tool_arguments",
+ "type": "string"
+ }
+ },
+ "required": [
+ "buttons"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "default_travelmode": {
+ "anyOf": [
+ {
+ "enum": [
+ "driving",
+ "walking",
+ "bicycling",
+ "transit"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Default travel mode used when the AI does not specify one."
+ },
+ "icon_url": {
+ "anyOf": [
+ {
+ "format": "uri",
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional URL of an icon to display inside the link button."
+ },
+ "object": {
+ "const": "google_maps_link_tool_arguments",
+ "default": "google_maps_link_tool_arguments",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "default_mode": {
+ "anyOf": [
+ {
+ "enum": [
+ "driving",
+ "walking",
+ "bicycling",
+ "transit",
+ "flying"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Default travel mode used when the AI does not specify one."
+ },
+ "object": {
+ "const": "google_maps_embed_tool_arguments",
+ "default": "google_maps_embed_tool_arguments",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "integration_id": {
+ "description": "ID of the connected Calendly integration to use for scheduling.",
+ "format": "uuid",
+ "type": "string"
+ },
+ "object": {
+ "const": "calendly_tool_arguments",
+ "default": "calendly_tool_arguments",
+ "type": "string"
+ }
+ },
+ "required": [
+ "integration_id"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]create_nodecreate_promptget_active_sessions_by_embedget_active_sessions_over_timeget_answer_type_distributionget_applicationget_sentiment_distributionget_top_cited_sourcesget_top_clicked_urlsget_top_devicesget_top_geographiesget_top_interaction_sourcesget_top_languagesget_top_localesget_top_searchesget_top_tagsget_trending_classificationslist_data_sourceslist_nodeslist_promptslist_toolsread_chat_request_documentsread_chat_request_tool_callsread_noderead_search_request_resultsread_session_detailread_sessionsread_toolupdate_chat_request_analyticsupdate_data_sourceupdate_nodeupdate_promptupdate_toolClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or metric. The many get_top_* endpoints are differentiated by the specific dimension measured, and read_* / list_* / get_* verbs consistently separate detail retrieval from aggregation and paginated listings. Explicit distinctions like get_top_languages vs get_top_locales and get_top_interaction_sources vs get_top_clicked_urls remove ambiguity.
Tool names follow a predictable verb_noun pattern: create_* for mutations that add, update_* for edits, list_* for paginated collections, read_* for detailed record access, and get_* for aggregate analytics. Even with 33 tools the naming convention is uniform and readable.
33 tools exceeds the 25+ threshold for 'too many' and is heavy for a single server surface. While the analytics getters are individually focused, the set is larger than typical for an MCP server and could be consolidated or grouped more tightly.
Analytics coverage is thorough, and nodes/prompts have create/read/update lifecycles. However, there are no delete operations anywhere, and data sources and tools support update but not create or delete, leaving notable lifecycle gaps for administrative tasks.