Crevio's MCP server lets an agent run a real online business, not just read from one. It exposes a delegation surface (ask_crevio, start_task, wait_for_run, send_message, resolve_approvals) plus code_search and code_execute for calling the full Crevio REST API - products, customers, orders, email, socials, and sites.
Scored across 14 tools
The API discovery/execution pair and the chat/run management tools have clearly separated concerns. The only mild overlap is between ask_crevio (delegate and wait) and start_chat/send_message (non-blocking or conversational), but their descriptions make the blocking/non-blocking distinction clear. No two tools appear to do the same job.
Most tools follow a clean verb_noun pattern (list_chats, send_message, wait_for_run, cancel_run). api_execute and api_search invert that pattern (noun_verb), and ask_crevio/whoami are special-purpose names, but the verbs are still consistent and recognizable.
14 tools fit the server's scope: one generic API execution pair, one whoami, and a complete run/chat lifecycle. Each tool corresponds to a distinct operation, and none feels redundant or like padding.
The run/chat lifecycle is well covered: start, continue, list, get, wait, cancel, and approve. However, ask_crevio's description explicitly references a start_task tool that is not exposed in the server, creating a dead end for longer asynchronous tasks. This is a notable gap in the otherwise coherent surface.
Execute Ruby in a sandboxed VM against the Crevio REST API. Use api_search first
to find the endpoint and its body fields, then call it here. Chain calls, transform
results, return the final expression.
get(path, params = {}) # paths auto-prefixed with /v1, routed in-process
post(path, **body) # body as keyword args or a hash — both work
patch(path, **body)
delete(path)
find_endpoints(query) # -> ["METHOD /path — summary", ...]
iso8601(offset_seconds = 0) # mruby Time has no strftime/iso8601Returns the last expression; puts is side-channel only. Every run answers
{result:, calls:, output:} — calls audits each REST call (method, path,
status, plus error_code/param on failure). When result has unexpected nils,
read calls for a non-2xx. Never project only success fields ({id: r["id"]}) —
that hides the error from result.
Params are unwrapped, Stripe-style: fields at the TOP level. {product: {...}} is
silently dropped by most endpoints.
Associations take the bare resource name and a prefix_id string — product: "prod_x",
never product_id:. Some required ones never appear in a schema's properties.
Courses and content live under /experiences, NOT /products.
Lists answer {object: "list", data: [...], has_more}; single resources answer the
object directly.
Connected integrations go through the same REST surface:
post("/connections/<id>/execute", tool: "<tool>", arguments: {...}), with ids from
get("/connections", search: "<service>").
Sandboxed mruby: no File, ENV, Net::HTTP, Process. 10s, 10 MB.
A product cannot be created active: it needs a price variant first, or the call 422s.
product = post("/products", name: "...")
post("/price_variants", product: product["id"], name: "Standard",
amount_type: "fixed", amount: 4900, currency: "usd", billing_type: "one_time")
patch("/products/#{product["id"]}", status: "active")API groups: Access, Account, Ads, Analytics, ApiKeys, Approvals, Audio, BlogCategories, BlogPosts, Bookings, Bots, Broadcasts, Calls, Chapters, CheckoutConfiguration, CheckoutLinks, Checkouts, Connections, Customers, Deployments, Discounts, Domains, Email, Email Suppressions, EventSessions, EventSources, EventTypes, Events, Experiences, Files, FormSubmissions, FormationDocuments, Formations, Forms, ForumPosts, Images, Invoices, Jobs, Leads, LegalPages, Lessons, LinkItems, Logs, Me, OrderItems, Orders, Phone Consents, Phone Numbers, Phone Suppressions, PriceVariants, Products, Refunds, Reviews, Schedules, Secrets, Sites, Skills, Socials, Status, Subscriptions, Tags, TaskRuns, Tasks, Topics, Usage, Users, Video, Web, WebhookEndpoints, WebhookEvents.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Ruby code to execute. Use get/post/patch/delete for REST access or find_endpoints to discover endpoints. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses substantial behavioral details: sandboxed mruby limitations ('no File, ENV, Net::HTTP, Process'), runtime constraints ('10s, 10 MB'), return shape ('{result:, calls:, output:}'), side-channel behavior of puts, in-process routing, path auto-prefixing, and Stripe-style parameter unwrapping. These are exactly the kind of hidden behaviors an agent needs to call the tool correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear headings and code blocks, delivering high-density, non-redundant guidance. The front-loaded purpose and workflow help immediate understanding, and while the API group list at the end is somewhat extensive, it still aids endpoint discovery.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description is remarkably complete: it explains the output envelope, the audit information in calls, error behavior, sandbox constraints, endpoint naming conventions, and even a realistic example with failure mode. Very little is left for the agent to guess.
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?
While the schema describes the code parameter at 100% coverage, the description greatly enriches its meaning by providing the exact callable helper functions with signatures, explaining that paths are auto-prefixed with /v1, and giving concrete Ruby examples. It also clarifies subtle semantics like the ordering trap and responses for list vs single resources.
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 precise statement: 'Execute Ruby in a sandboxed VM against the Crevio REST API.' It clearly identifies the tool's action (execute), resource (REST API), and environment (sandboxed VM), and distinguishes it from the sibling api_search by instructing the agent to discover endpoints there first.
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 tells the agent when to use this tool: 'Use api_search first to find the endpoint and its body fields, then call it here.' It also explains the broader workflow of chaining calls, transforming results, and returning the final expression, naming the alternative tool for discovery rather than execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover available Crevio API endpoints. Use this BEFORE api_execute when you're unsure which endpoint to call, need to check parameter names, or want to explore what's available for a domain (e.g. "experiences", "discounts"). A tools method returns the full API catalog — an array of hashes keyed with strings: "method", "path", "summary", "description", "tags", "parameters", "request_body". Examples: tools.select { |t| t["tags"]&.include?("Products") }.map { |t| "#{t["method"]} #{t["path"]} — #{t["summary"]}" } tools.find { |t| t["path"].include?("price_variants") && t["method"] == "POST" }["request_body"] tools.map { |t| t["tags"] }.flatten.compact.uniq.sort — list all API domains
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Ruby code to execute. Use `tools` to access the API catalog and filter/search it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the description's added return-shape detail is valuable: a full catalog array of hashes with named keys. It does not mention possible Ruby execution errors or large-result considerations, but these are not critical given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage, and every section is relevant. The example block is dense and runs as one long line, so splitting it into a scannable bullet list would improve structure without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because there is no output schema, the description takes on the responsibility of describing the return value, and it does so by listing the hash keys and showing multiple example expressions. The annotations, input schema, and sibling context together make this description complete enough for an agent to use 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 schema already documents the `code` parameter at 100%, but the description goes further by giving three concrete Ruby-level examples that show filtering by tag, finding a specific request body, and listing domains. This provides practical meaning beyond the schema's single descriptive sentence.
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 concrete verb and resource: 'Discover available Crevio API endpoints.' It also names the sibling `api_execute` and positions `api_search` as the discovery/exploration tool, which distinguishes it from the other sibling tools without needing to open their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this BEFORE `api_execute` when unsure of the endpoint, parameter names, or domain details, which is a strong positive usage rule. However, it does not state the negative case explicitly, such as 'if you already know the exact endpoint, call api_execute directly'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delegate a job to the Crevio agent and wait for the result. Starts a run that works your account through the Crevio API (products, customers, orders, email, socials, sites, research), waits up to timeout_seconds, and returns the run with the agent's final reply in result. For anything longer, use start_task and wait_for_run.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | What you want done, in natural language. | |
| approval_mode | No | autonomous (default) acts without review; supervised pauses in needs_input for your review before finishing; read_only forbids writes. | |
| idempotency_key | No | Retrying with the same key returns the run the first call started instead of starting another. | |
| timeout_seconds | No | How long to wait for the run to settle before returning (default 60, max 90). On wait_timed_out, call wait_for_run with the run id. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| object | Yes | |
| result | No | |
| reused | No | |
| status | Yes | |
| chat_id | No | |
| summary | No | |
| task_id | Yes | |
| task_name | No | |
| created_at | Yes | |
| started_at | No | |
| completed_at | No | |
| error_message | No | |
| credits_consumed | No | |
| pending_approval_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the blocking/waiting behavior ('waits up to timeout_seconds'), the run lifecycle it starts, the breadth of account access, and where the agent's answer appears (`result`). This adds meaningful context beyond annotations — openWorldHint and readOnlyHint=false only signal external effects and writability, not the timeout/run semantics — without contradicting them.
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 filler: core action, scope, wait/return semantics, and the alternative are each covered once. The most decision-relevant information 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?
With an output schema, annotations, and thorough per-parameter schema descriptions present, the description only needs to cover non-obvious behavior — it covers synchronous waiting, timeout handling, the run/result shape, and sibling routing. The only minor gap is not stating up front that the tool can mutate account state, though readOnlyHint=false and 'works your account' imply it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter (message, approval_mode, idempotency_key, timeout_seconds) already has a descriptive schema entry including defaults, constraints, and timeout guidance. The description's reference to timeout_seconds and `result` slightly reinforces behavior, but it adds no per-parameter meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource: 'Delegate a job to the Crevio agent and wait for the result.' It enumerates the account domains the agent works across (products, customers, orders, email, socials, sites, research) and names the return behavior (run with final reply in `result`), which distinguishes it from sibling run-management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when not to use it: 'For anything longer, use start_task and wait_for_run.' This gives the agent a clear routing condition between the synchronous all-in-one call and the async split approach, with no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a run that is pending, running, or waiting for input. The run is finalized as failed with 'Cancelled by the caller'.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | A run id (trun_...). |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| object | Yes | |
| result | No | |
| reused | No | |
| status | Yes | |
| chat_id | No | |
| summary | No | |
| task_id | Yes | |
| task_name | No | |
| created_at | Yes | |
| started_at | No | |
| completed_at | No | |
| error_message | No | |
| credits_consumed | No | |
| pending_approval_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond the annotations by stating the outcome: the run is finalized as failed with a specific cancellation message. This complements the destructiveHint and confirms the effect of the 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 concise sentences with no filler. The action and applicable states are front-loaded, followed by the finalization consequence, making every sentence informative.
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 one-parameter cancellation tool with an output schema present and strong annotations, the description covers the key operational context: when it can be invoked and what the result will be. No critical information 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 fully documents the only parameter, run_id, including its format (trun_...). The description does not add parameter-level meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Stop') with a clear resource ('a run') and enumerates the applicable states: pending, running, or waiting for input. This makes the tool's purpose unambiguous and distinguishes it from sibling tools like get_run, list_runs, and wait_for_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when the tool applies by listing the run states it can act on. It does not explicitly name alternatives or exclusion conditions, but the state condition is specific enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a chat's title, kind, and latest run.
| Name | Required | Description | Default |
|---|---|---|---|
| chat_id | Yes | A chat id (aichat_...). A run id works too — it resolves to that run's chat. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| title | No | |
| object | Yes | |
| created_at | Yes | |
| updated_at | No | |
| context_type | No | |
| latest_run_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The parameter schema adds a meaningful behavior—accepting a run id and resolving it to its chat—which goes beyond the annotations. The description itself adds no further behavioral detail, but with annotations present the bar is met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Each phrase ('title, kind, and latest run') adds concrete scope, and nothing is repeated from 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?
For a one-parameter, read-only tool with an output schema and safety annotations, the description is sufficient to invoke correctly. It could be improved by an explicit note that this is the lightweight chat-metadata alternative to get_run, but that is optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the chat_id property is fully documented, including the id prefix and the run-id fallback. The tool description adds no parameter-level detail beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Get' applied to the 'chat' resource and enumerates the returned fields ('title, kind, and latest run'), making the operation unambiguous. It does not explicitly name sibling tools, but the field list differentiates it from get_run and list_chats.
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?
There is no explicit when-to-use or alternatives mentioned; the sentence only states what the tool returns. The schema's note that a run id can be supplied offers some input guidance, but not tool-selection guidance. Usage is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a run's current status, summary, pending approvals, and (once settled) the agent's final reply.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | A run id (trun_...). |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| object | Yes | |
| result | No | |
| reused | No | |
| status | Yes | |
| chat_id | No | |
| summary | No | |
| task_id | Yes | |
| task_name | No | |
| created_at | Yes | |
| started_at | No | |
| completed_at | No | |
| error_message | No | |
| credits_consumed | No | |
| pending_approval_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the description does not need to restate those. It adds one useful behavioral detail—the final reply is only available 'once settled'—but provides no context on error behavior, unsettled-run responses, or how pending approvals should be 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 a single front-loaded sentence with no filler. It states the action, the resource, and the key returned data points efficiently, and every phrase contributes meaning.
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 one-parameter, read-only fetch with a full output schema and strong annotations, this description is complete. It does not need to explain return shapes because the output schema handles that, and no essential invocation detail 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?
There is only one parameter, run_id, and the schema already documents it fully with 100% coverage. The description correctly refers to 'a run' but adds no new parameter-level detail; the schema already carries the 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 opens with the specific verb 'Fetch' and clearly identifies the resource: a single run. It then enumerates exactly what will be returned—current status, summary, pending approvals, and the agent's final reply once settled—which distinguishes it from listing or waiting tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for inspecting a specific run's status and outputs, but it never explicitly names sibling alternatives like wait_for_run, list_runs, or resolve_approvals. The intended use is inferable but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the account's chats, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 20. | |
| search | No | Only chats whose title matches. | |
| ending_before | No | Return the page before this id — the first id from the previous page. | |
| starting_after | No | Return the page after this id — the last id from the previous page. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| object | Yes | |
| has_more | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose that the tool is read-only, idempotent, and non-destructive, so the description does not need to repeat that. It adds the 'newest first' ordering, which is genuinely useful, but says nothing about pagination behavior or result bounds; the cursor parameters in the schema cover most of the rest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler: it gives the action, scope, and ordering immediately. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the schema fully documents all parameters and an output schema exists, the description is largely sufficient for a simple list tool. It could be more complete by pointing at get_chat or list_messages for related operations, but the core account-scoped list semantics are clear.
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 input schema already documents limit, search, ending_before, and starting_after. The description contributes no additional parameter meaning beyond what the schema provides, so it does not exceed the baseline.
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 exact verb ('List'), the resource ('the account's chats'), and the ordering ('newest first'), so an agent knows precisely what this tool does. This also separates it from siblings like get_chat (single chat vs. list) and list_messages/list_runs (different resource).
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?
There is no guidance about when to choose this tool over siblings such as get_chat or list_messages, and no mention of alternatives or exclusions. The only implied context is the resource name itself, which is not enough to direct an agent deciding among the list-type tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a chat's messages, oldest first. Returns the most recent limit messages; page back through older ones with starting_after.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 50. | |
| chat_id | Yes | A chat id (aichat_...). A run id works too — it resolves to that run's chat. | |
| ending_before | No | Return the messages older than this id — the first id of the previous page. Paging walks backwards through history, since the default page is the tail. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| object | Yes | |
| has_more | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the readOnlyHint and idempotentHint annotations: oldest-first ordering and tail-based paging. However, it instructs callers to 'page back through older ones with starting_after,' which directly contradicts the schema where the actual paging parameter is ending_before. This misleading behavior guidance is a significant flaw.
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 short and front-loaded with the core purpose, which is good. However, the second clause introducing starting_after is inaccurate and does not earn its place, undermining what would otherwise be a concise, well-structured one-liner.
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?
Annotations and the output schema cover safety and return values, and the schema documents ending_before well. However, the description's incorrect pagination instruction leaves the agent without reliable guidance for the exact workflow it claims to explain—reading older pages. For a paginated read tool, this is a material completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description does add semantics around limit ('most recent limit messages'). Yet it names starting_after, which is not present in the schema, and never references the real ending_before parameter. The parameter guidance is therefore actively misleading rather than additive.
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: 'Read a chat's messages, oldest first.' This clearly distinguishes it from siblings like list_chats, get_chat, and send_message. The core purpose is unambiguous despite later pagination wording issues.
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 reading a chat's message history and gives ordering/pagination context. However, it does not explicitly state when to prefer this over siblings like list_chats or get_chat, and the pagination advice names a parameter that does not exist in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the account's task runs, newest first — delegated jobs and scheduled tasks alike. Filter by status or task.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 20. | |
| status | No | Only runs in this state. | |
| task_id | No | Only runs of this task (task_...). | |
| ending_before | No | Return the page before this id — the first id from the previous page. | |
| starting_after | No | Return the page after this id — the last id from the previous page. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| object | Yes | |
| has_more | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds genuinely useful behavioral context beyond that: the 'newest first' ordering and the inclusive result scope of 'delegated jobs and scheduled tasks alike.' It does not disclose pagination limits or behavior on large result sets, but the schema's starting_after/ending_before parameters partially signal this.
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 zero filler. The main action and resource are front-loaded, followed by the ordering and scope distinction, then the filtering capabilities. Every clause earns its place and nothing is repeated from the schema.
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 100% schema coverage, four strong safety annotations, and a present output schema, the description covers the essentials an agent needs: object of the listing, ordering, scope, and filter options. The only notable gap is the absence of a pointer toward get_run for single-run detail, but this is a minor omission for a straightforward list operation.
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% — all five parameters (limit, status, task_id, ending_before, starting_after) already carry descriptions, so the baseline is 3. The description's 'Filter by status or task' merely restates what the status and task_id schema entries already document and adds no format, syntax, or interaction details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('the account's task runs') and adds distinguishing scope: 'delegated jobs and scheduled tasks alike' signals comprehensive coverage and separates it from singular-run siblings like get_run. The ordering ('newest first') and filter capabilities further pin down exactly 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 description implies when to use the tool — when you need an ordered, filterable enumeration of runs — but it does not explicitly name alternatives or exclusions. Siblings like get_run, wait_for_run, and cancel_run exist, and no guidance is given for choosing among them, leaving the agent to infer that listing is distinct from retrieving, waiting on, or canceling a single run.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Approve or deny the integration actions a run is paused on (status needs_input with pending_approval_ids). Submit a decision for every pending id at once; the run resumes in the background.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | A run id (trun_...). | |
| approvals | Yes | One decision per pending approval id — the run stays paused until every one is answered. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| object | Yes | |
| result | No | |
| reused | No | |
| status | Yes | |
| chat_id | No | |
| summary | No | |
| task_id | Yes | |
| task_name | No | |
| created_at | Yes | |
| started_at | No | |
| completed_at | No | |
| error_message | No | |
| credits_consumed | No | |
| pending_approval_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the important behavioral effect: the run resumes in the background after decisions are submitted. The schema also notes the run stays paused until every approval is answered. Annotations already indicate this is a non-read-only, non-idempotent operation, and the description aligns with that rather than contradicting it.
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 compact sentences with no filler. The action, the trigger condition, the all-pending-ids requirement, and the post-call behavior are all presented efficiently and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with 100% schema coverage and an output schema present, the description is complete enough. It tells the agent when to invoke, what inputs are expected, the all-at-once constraint, and what happens to the run afterward. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both run_id and approvals are already well documented. The description reinforces the 'all at once' requirement but does not add meaningful format or syntax details beyond what the schema provides. This is the appropriate baseline when the schema carries the parameter-documentation 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 uses a specific verb and resource: 'Approve or deny the integration actions a run is paused on.' It also gives the exact triggering state, 'status needs_input with pending_approval_ids,' making it easy to distinguish from sibling tools like cancel_run or get_run.
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 states when to use the tool: when a run is paused with pending approval ids. It also states the required usage behavior: submit a decision for every pending id at once. However, it does not mention alternatives or explicitly say when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Continue a chat with follow-up instructions or answers — the agent keeps its context. Resumes a run waiting in needs_input, or queues a new run when the last one finished. Returns run_busy while a run is still in progress. Optionally waits for the reply.
| Name | Required | Description | Default |
|---|---|---|---|
| chat_id | Yes | A chat id (aichat_...). A run id works too — it resolves to that run's chat. | |
| message | Yes | The follow-up to send into the conversation. | |
| timeout_seconds | No | Seconds to wait for the reply before returning (default 0: return the new run immediately). |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| object | Yes | |
| result | No | |
| reused | No | |
| status | Yes | |
| chat_id | No | |
| summary | No | |
| task_id | Yes | |
| task_name | No | |
| created_at | Yes | |
| started_at | No | |
| completed_at | No | |
| error_message | No | |
| credits_consumed | No | |
| pending_approval_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses useful non-obvious behavior: returning run_busy while a run is in progress, resuming vs. queuing depending on run state, and optionally waiting for the reply. This adds real context to the readOnlyHint=false, destructiveHint=false annotation set.
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 tight sentences with no filler. The main purpose is front-loaded, and each sentence adds distinct, useful information: context preservation, the resume/queue mechanics, and the busy/wait behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavior for calling the tool correctly: what it does, the run-state conditions, the busy response, and the optional wait. With an output schema present and full parameter documentation, nothing critical is left unexplained.
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 all parameters well. The description reinforces the timeout_seconds behavior ('Optionally waits for the reply') but does not substantially add meaning beyond the schema's own parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Continue a chat'), the resource (chat/run), and the core semantic ('the agent keeps its context'). It clearly differs from sibling tools like start_chat, since it explicitly frames itself as continuing an existing conversation rather than starting one.
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 concrete conditions for when the tool is used: it resumes a run waiting in needs_input, or queues a new run after the previous run finished. It also explains the busy case and optional waiting, giving the agent practical context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a chat with the Crevio agent and queue a run, without waiting. Returns the run immediately — its chat_id is the conversation to continue with send_message. Follow the run with wait_for_run or get_run.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | What you want done, in natural language. | |
| approval_mode | No | autonomous (default) acts without review; supervised pauses in needs_input for your review before finishing; read_only forbids writes. | |
| idempotency_key | No | Retrying with the same key returns the run the first call started instead of starting another. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| object | Yes | |
| result | No | |
| reused | No | |
| status | Yes | |
| chat_id | No | |
| summary | No | |
| task_id | Yes | |
| task_name | No | |
| created_at | Yes | |
| started_at | No | |
| completed_at | No | |
| error_message | No | |
| credits_consumed | No | |
| pending_approval_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-idempotent operation, so the bar is lower. The description adds useful behavioral context beyond annotations: the tool queues a run without waiting, returns the run immediately, and links the returned chat_id to subsequent send_message calls. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The key behavioral distinction (without waiting) is front-loaded, and the follow-up workflow is presented compactly with named sibling tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and all parameters are fully documented, the description covers the essential selection and invocation context: what the tool does, how it differs from siblings, and what to do with the returned run. 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%, with all three parameters already explained, including approval_mode enum values and idempotency_key retry behavior. The description adds no extra parameter semantics, 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?
The description clearly states the tool's action: it opens a chat with the Crevio agent, queues a run, and returns immediately without waiting. It also names send_message, wait_for_run, and get_run, which helps distinguish this tool from its 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?
The description explicitly explains the asynchronous behavior ('without waiting') and provides the follow-up workflow: use send_message with the returned chat_id, and follow the run with wait_for_run or get_run. This is clear when-to-use guidance relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for a run to settle (completed, failed, or needs_input) and return it with the agent's final reply. Returns wait_timed_out if it is still running when the timeout passes; call again.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | A run id (trun_...). | |
| timeout_seconds | No | How long to wait for the run to settle before returning (default 60, max 90). On wait_timed_out, call wait_for_run with the run id. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| object | Yes | |
| result | No | |
| reused | No | |
| status | Yes | |
| chat_id | No | |
| summary | No | |
| task_id | Yes | |
| task_name | No | |
| created_at | Yes | |
| started_at | No | |
| completed_at | No | |
| error_message | No | |
| credits_consumed | No | |
| pending_approval_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals blocking/settling behavior, possible terminal states (completed, failed, needs_input), the wait_timed_out outcome, and retry semantics. Annotations already cover read-only/idempotent safety, and the description adds useful operational context beyond them.
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 purpose and then efficiently cover timeout and retry behavior. There is no filler and no redundant repetition of annotation or schema 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?
This is a simple two-parameter polling tool with a full input schema, an output schema, and annotations covering safety. The description covers the lifecycle outcome, timeout condition, and next step, 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?
Both parameters are fully described in the schema, including run_id format and timeout_seconds default/max/retry behavior. The description mostly restates the retry instruction and adds no new parameter-level meaning, 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 names a specific verb (wait), resource (run), and outcome (settled run with final reply). The terminal states and timeout return clearly differentiate it from get_run, so an agent knows exactly 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?
It gives explicit retry guidance on wait_timed_out: call again with the run id. It does not explicitly contrast get_run or other siblings, but the wait-vs-get distinction is clear enough for competent selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify the account, user, and credential behind this connection, with plan, credit balance, rate limits, and the tools available. Call it first to verify the setup.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| user | No | |
| tools | Yes | |
| limits | No | Bounds the delegation tools enforce. |
| object | Yes | |
| account | Yes | The account every tool call is scoped to. |
| credits | Yes | |
| credential | Yes | How this connection authenticated. |
| rate_limit | No | The API rate limit this credential is subject to. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds valuable behavioral context by enumerating what the call returns: account identity, plan, credit balance, rate limits, and available tools—information beyond what the empty schema conveys.
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 front-loads purpose and returned data, the second gives a clear usage directive. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with rich annotations (readOnly, idempotent, openWorld) and an output schema, the description fully covers what an agent needs to select and invoke the tool correctly. No important gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema description coverage, the baseline is 4. The description appropriately focuses on the output and invocation context rather than parameters, and no parameter documentation 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 uses a specific verb ('Identify') and specifies the resources: account, user, and credential behind the connection, plus plan, credit balance, rate limits, and available tools. This clearly distinguishes it from sibling tools that manage chats, runs, and messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit contextual guidance: 'Call it first to verify the setup.' It does not name alternatives or exclusions, but as an identity/verification tool, it has no direct sibling, making the instruction sufficient.
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.
ask_crevio1 field changedOutput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input",
- "timed_out"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out",
+ "unknown"
+]cancel_run1 field changedOutput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input",
- "timed_out"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out",
+ "unknown"
+]get_run1 field changedOutput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input",
- "timed_out"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out",
+ "unknown"
+]list_runs2 fields changedInput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input",
- "timed_out"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out",
+ "unknown"
+]Output schema / properties / data / items / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input",
- "timed_out"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out",
+ "unknown"
+]resolve_approvals1 field changedOutput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input",
- "timed_out"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out",
+ "unknown"
+]send_message1 field changedOutput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input",
- "timed_out"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out",
+ "unknown"
+]start_chat1 field changedOutput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input",
- "timed_out"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out",
+ "unknown"
+]wait_for_run1 field changedOutput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input",
- "timed_out"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out",
+ "unknown"
+]ask_crevio1 field changedOutput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out"
+]cancel_run1 field changedOutput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out"
+]get_run1 field changedOutput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out"
+]list_runs2 fields changedInput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out"
+]Output schema / properties / data / items / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out"
+]resolve_approvals1 field changedOutput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out"
+]send_message1 field changedOutput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out"
+]start_chat1 field changedOutput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out"
+]wait_for_run1 field changedOutput schema / properties / status / enumPrevious value: -[
- "pending",
- "running",
- "completed",
- "failed",
- "needs_input"
-]New value: +[
+ "pending",
+ "running",
+ "completed",
+ "failed",
+ "needs_input",
+ "timed_out"
+]api_executeapi_searchask_creviocancel_runget_chatget_runlist_chatslist_messageslist_runsresolve_approvalssend_messagestart_chatwait_for_runwhoami
