The agent-native cloud: database, functions, AI, storage, computers. 55 tools, one API key.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 46 of 46 tools scored. Lowest: 2.9/5.
Most tools have clearly distinct purposes within their domains, but the five 'COMING SOON' scalix_compute_* tools are confusing placeholders that redirect to alternatives, potentially causing misselection. The database tools are well-differentiated.
All tools follow a consistent 'scalix_<domain>_<action>' pattern (e.g., scalix_db_query, scalix_run_deploy). Even placeholder tools adhere to this pattern, making the naming highly predictable.
46 tools is on the higher side for a single server. While the broad coverage justifies many tools, the inclusion of five non-functional placeholders inflates the count unnecessarily. The actual available toolset is still substantial but not excessive.
The server covers many domains (AI, database, storage, compute, etc.) but has notable gaps: no scalix_build_list, no project deletion, no secrets management, and the compute tools are not yet functional. Core workflows exist but are incomplete.
scalix_ai_inferAInspectRun AI inference on Scalix AI — the Scalix Lumio model family. Sends a prompt and returns the model's response in the OpenAI-compatible chat-completions format; tokens are billed to the project's credit pool. Discover available model IDs with scalix_ai_models.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model ID (from scalix_ai_models, e.g. a Scalix Lumio variant) | |
| prompt | Yes | User prompt / message | |
| system | No | System message | |
| max_tokens | No | Maximum tokens to generate | |
| temperature | No | Sampling temperature (0-2) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that tokens are billed to the project's credit pool and that the output format is OpenAI-compatible chat-completions. This adds significant value beyond a simple 'run inference' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences covering purpose, output format, billing, and a pointer to the sibling tool. Every sentence is informative and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description covers the essential behavior: inference, output format, billing, and model sourcing. It could mention error handling or synchronous nature, but is adequate for a straightforward LLM inference 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%, so baseline is 3. The description adds minimal extra context beyond the schema, only referencing that the model parameter should come from scalix_ai_models. It does not enhance understanding of prompt, system, max_tokens, or temperature.
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 runs AI inference on the Scalix Lumio model family, specifying that it sends a prompt and returns an OpenAI-compatible chat-completions response. It also mentions billing to the project's credit pool, distinguishing it from the sibling tool scalix_ai_models which only lists models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs users to 'Discover available model IDs with scalix_ai_models,' providing a direct link to a prerequisite tool. While it doesn't list when not to use this tool or alternatives, the context is clear for an inference call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_ai_modelsAInspectList the AI models available to the project — the Scalix Lumio family and any models enabled for the org — with their IDs for use in scalix_ai_infer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the read operation and intended use, but doesn't disclose additional behavioral traits like caching, rate limits, or side effects. 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?
Single concise sentence that is front-loaded with the main action and includes relevant details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple listing tool with no inputs. Lacks explicit mention of output format (e.g., fields returned), but the purpose and context 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?
No parameters in schema, so no parameter info needed. Description does not add param details, but baseline of 4 applies for zero-parameter tools.
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?
Clearly states it lists AI models available to the project, specifying the scope (Scalix Lumio family and org-enabled models) and the explicit purpose (providing IDs for use in scalix_ai_infer). This distinguishes it from sibling tools like scalix_ai_infer.
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?
Implied usage: use before scalix_ai_infer to get model IDs. No explicit when-not or alternatives, but the mention of scalix_ai_infer provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_auth_configureAInspectConfigure end-user authentication for the project — require MFA, require email confirmation, and set the allowed auth providers.
| Name | Required | Description | Default |
|---|---|---|---|
| mfa_enabled | No | Require multi-factor authentication | |
| allowed_providers | No | Allowed auth providers (e.g., ["email", "google", "github"]) | |
| require_email_confirmation | No | Require users to confirm their email before a session is issued |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes what the tool configures but does not disclose side effects (e.g., whether existing sessions are invalidated, if the project must be created first, or if settings are reversible). This is insufficient for a mutation 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 single sentence, front-loaded with the verb, and lists the three configurable aspects. Every word earns its place; 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 the tool's moderate complexity (3 parameters, boolean/array), no output schema, and no annotations, the description is adequate but incomplete. It lacks behavioral context such as whether configuration is immediate or requires a rebuild, and does not address potential impacts on other services.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description groups the parameters into actions but adds no additional meaning beyond the parameter descriptions in the schema. It does not clarify constraints or formats not already present.
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 'Configure' and the resource 'end-user authentication', and lists specific actions (require MFA, require email confirmation, set allowed providers). It distinguishes itself from sibling tools, none of which deal with authentication 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 does not provide explicit guidance on when to use this tool or alternatives. Usage is implied by the tool's purpose, but no context such as prerequisites (e.g., project must exist) or ordering relative to other tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_build_createAInspectCreate a new container image build from a Git repository or Dockerfile.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Build name | |
| branch | No | Git branch | main |
| git_url | Yes | Git repository URL | |
| dockerfile | No | Path to Dockerfile in repo | Dockerfile |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states 'Create a new container image build' without noting permissions, side effects, or whether it overwrites existing builds. This is insufficient for a creation 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 a single sentence with no extraneous words, making it concise and direct.
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 no output schema and the description does not mention what the tool returns (e.g., build ID or status). For a creation tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds marginal value by mentioning 'Git repository or Dockerfile', which maps to git_url and dockerfile parameters, but does not elaborate on name or branch beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('container image build') and clearly distinguishes this tool from siblings like scalix_build_status, as it is the only creation tool for builds.
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 states the sources for creating a build (Git repository or Dockerfile), providing clear context. However, it does not explicitly mention when not to use this tool or name alternatives such as deployment tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_build_statusBInspectGet the status and logs of a build.
| Name | Required | Description | Default |
|---|---|---|---|
| build_id | Yes | Build ID to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully convey behavioral traits. It only states it gets status and logs, but does not disclose any side effects (likely none), authentication needs, rate limits, or what constitutes a valid build. The description is too minimal for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. However, it is extremely brief and lacks any additional structure or details that could be useful, mildly penalizing conciseness for slight under-specification.
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 low complexity (single required parameter, no output schema), the description adequately states the basic purpose. However, it does not explain the return format or provide enough context for the agent to fully understand the tool's behavior, missing opportunities for 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 100% (one parameter 'build_id' with a description). The tool description adds no additional meaning beyond the schema, such as expected format or source of the build ID. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the status and logs of a build' uses a specific verb ('Get') and clearly identifies the resource ('status and logs of a build'). It distinguishes itself from the sibling tool 'scalix_build_create' which creates a build.
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 provided on when to use this tool versus alternatives (e.g., scalix_build_create, scalix_status). There are no instructions on prerequisites, context for valid build IDs, or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_compute_deleteAInspectCOMING SOON — not available yet. Container deployments are not built yet; this returns 501. Delete a Scalix Run service with scalix_run_delete instead.
| Name | Required | Description | Default |
|---|---|---|---|
| deployment_id | Yes | ID of the deployment to permanently delete (from scalix_compute_list) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently discloses that the tool returns a 501 error, which is the key behavioral trait. It also directs to an alternative, providing full transparency about current 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 extremely concise with two short sentences, zero waste. It conveys essential information without any extraneous 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?
Given the tool is not functional, the description is complete: it explains the current state (returns 501), the intended purpose (delete), and the alternative. No additional information is needed for this 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?
The input schema covers the single parameter with a description ('ID of the deployment to permanently delete from scalix_compute_list'). The tool description does not add additional semantics beyond the schema. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool is not yet available and returns a 501 error. It specifies the intended action (deleting a compute deployment) and provides a direct sibling alternative (scalix_run_delete), making the purpose unmistakable.
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 'COMING SOON — not available yet' and directs the agent to use scalix_run_delete instead. This provides clear when-not-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_compute_deployAInspectCOMING SOON — not available yet. Long-running container deployments are not built yet; this returns 501. To run containers today use scalix_run_deploy (Scalix Run services) or scalix_fn_deploy (Functions).
| Name | Required | Description | Default |
|---|---|---|---|
| env | No | Environment variables as key-value pairs | |
| name | Yes | Deployment name | |
| image | Yes | Container image (e.g., nginx:latest) | |
| replicas | No | Number of replicas | |
| cpu_cores | No | CPU cores per instance | |
| memory_mb | No | Memory per instance in MB |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool is not built and will return HTTP 501. This is a clear behavioral description, especially given no annotations were provided.
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, no fluff. Front-loaded with the most critical information (unavailability) and immediate guidance on alternatives.
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 incomplete state, the description is fully adequate. It communicates what an agent needs to know: don't call this, use these alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add additional meaning to the parameters beyond what the 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?
Description clearly states the tool's purpose (long-running container deployments) and its current unavailability. It distinguishes from sibling tools by explicitly naming scalix_run_deploy and scalix_fn_deploy as alternatives for running containers today.
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 tells the agent not to use this tool yet ('not available', 'returns 501') and provides clear alternatives: 'use scalix_run_deploy or scalix_fn_deploy'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_compute_listAInspectCOMING SOON — not available yet. Container deployments are not built yet; this returns 501. Use scalix_run_list / scalix_fn_list instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the key behavioral trait: the tool is not implemented and returns HTTP 501. This is beyond what the name suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two front-loaded sentences. Every word serves a purpose: flagging unavailability, explaining why, and directing to working alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a placeholder, the description completely covers what an agent needs: that the tool is non-functional and what to use instead. No output schema needed.
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, baseline is 4. The description adds no parameter info because none exist, which 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 is not available yet, what it would do (list container deployments), and that it returns 501. It explicitly distinguishes from sibling tools by naming 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?
The description explicitly instructs to use scalix_run_list or scalix_fn_list instead, providing clear guidance on when not to use this tool and what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_computer_createAInspectGet or create a persistent Linux machine by name. Idempotent — calling it again with the same name returns the existing machine rather than creating another, so it is safe to retry. Unlike a sandbox, the disk survives stop/start and is only erased by scalix_computer_delete.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Machine name: lowercase letters, digits and hyphens, max 63 characters. Unique to you. | |
| vcpus | No | vCPUs, 1-16 (default 1). Ignored if the machine already exists. | |
| disk_gb | No | Root disk in GB, 5-200 (default 10). Fixed at create — disks do not grow. Ignored if the machine already exists. | |
| ssh_keys | No | OpenSSH public keys to authorise for root, max 32, e.g. ["ssh-ed25519 AAAAC3Nz… you@laptop"]. Only needed if a human will ssh in — exec, write_file and read_file all work without one. Send the public half only; a private key is rejected. Ignored if the machine already exists — use scalix_computer_set_ssh_keys to change them. Supplying this needs the sandbox:execute scope on top of sandbox:create, because a key is a root shell; omit it and sandbox:create alone is enough. | |
| memory_mb | No | Memory in MB, 512-32768 (default 1024). Ignored if the machine already exists. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses idempotency, disk persistence across stop/start, and that deletion only happens via scalix_computer_delete. It does not mention auth requirements or error behavior, but the core behavioral traits are well covered.
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. Every sentence adds value: definition, idempotency, and persistence/lifecycle. No fluff or 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?
Given no annotations and no output schema, the description explains purpose, idempotency, persistence, and deletion path. It lacks guidance on return values/errors and could name sibling alternatives more explicitly, but it is largely complete for a create tool with rich schema descriptions.
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%, and parameter descriptions are already detailed (constraints, defaults, 'ignored if exists', ssh_keys nuances). The tool description adds no additional parameter-level semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Get or create a persistent Linux machine by name.' It clearly distinguishes itself from a sandbox by highlighting persistence and idempotency, which sets it apart from sibling compute tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly contrasts with a sandbox ('Unlike a sandbox, the disk survives stop/start'), implying use this when persistence is needed and a sandbox when not. It also notes idempotency for safe retries. However, it does not explicitly name alternative tools like scalix_sandbox_run or scalix_compute_deploy, leaving some ambiguity for complex decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_computer_deleteAInspectPermanently delete a persistent Linux machine AND its disk. This cannot be undone — use scalix_computer_stop if you may want the files back.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Machine id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses irreversibility ('cannot be undone'), permanent deletion, and the scope of deletion (machine AND disk). With no annotations, this fully compensates and gives the agent a clear safety profile.
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: first states the action and object, second warns of irreversibility and names the alternative. Zero wasted words, information 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 single-parameter delete tool, the description covers the essential context: what gets deleted, permanence, and the safer alternative. No gaps 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?
Schema coverage is 100% for the single parameter 'id' (described as 'Machine id'). Description adds marginal context by specifying 'persistent Linux machine', but essentially restates 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?
Description states the specific verb 'delete' targeting 'persistent Linux machine AND its disk', clearly differentiating from scalix_computer_stop which preserves files. The permanence is highlighted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'use scalix_computer_stop if you may want the files back', providing a clear alternative and when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_computer_execAInspectRun a command inside a persistent Linux machine and wait for it to finish. Returns exit code, stdout and stderr. The machine must be running.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Machine id from scalix_computer_create or scalix_computer_list | |
| cwd | No | Working directory inside the machine | |
| env | No | Environment variables for this command only | |
| args | No | Arguments, e.g. ["-lc", "npm test"] | |
| command | Yes | Program to run, e.g. bash | |
| timeout_ms | No | Give up after this many milliseconds, 1000-600000 (default 120000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions waiting and return values, but for an arbitrary command execution tool, it fails to warn that commands may modify the persistent machine or that execution can block until timeout. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with the main action front-loaded. No wasted words; every sentence provides essential information (action, return values, prerequisite).
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 6-parameter schema covers parameter details, the description adequately covers purpose, return values, and the key prerequisite of a running machine. It lacks explicit mention of timeout behavior or side effects, but those are partially inferable from schema and the nature of execution, making it fairly 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 all parameters are already well-documented. The description does not add parameter semantics beyond mentioning return values, aligning with the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Run a command), the resource (persistent Linux machine), and the outcome (wait for it to finish, returns exit code, stdout, stderr). It distinguishes from siblings like scalix_computer_read_file/write_file by focusing on execution rather than file operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use this to execute commands on a persistent machine, with an explicit prerequisite that the machine must be running. However, it does not mention alternatives or exclusions, such as scalix_sandbox_run for ephemeral environments, so it stops short of a full when/when-not guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_computer_listAInspectList your persistent Linux machines with their status, address and resource shape.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must convey behavior. The verb 'List' clearly indicates a read-only operation, and the description adds the returned fields (status, address, resource shape). It does not mention rate limits or pagination, but these are minor for a simple listing 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 single, well-structured sentence that leads with the action and resource. Every word contributes meaning, with 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 zero-parameter list tool, the description provides adequate context: it specifies the resource type and the output fields. It could mention whether the list is ordered or paginated, but these are not critical for the tool's basic purpose. Overall, the description is sufficiently 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?
The tool has zero parameters, so the empty schema fully documents the interface. The baseline for 0-parameter tools is 4, and the description neither adds nor requires parameter details. It correctly implies no inputs are 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 clearly states the action ('List'), the specific resource ('your persistent Linux machines'), and the included details (status, address, resource shape). This distinguishes it from sibling tools like scalix_compute_list by highlighting the persistent Linux machine scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as scalix_compute_list or scalix_computer_create. The description implies usage for listing persistent machines but does not provide selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_computer_read_fileBInspectRead a text file out of a persistent Linux machine.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Machine id | |
| path | Yes | Absolute path inside the machine |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the basic action and target ('text file', 'persistent Linux machine') but does not mention error behavior, permissions, encoding, or file size limits. This is insufficient for a tool with no annotation 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?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose without 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?
For a simple two-parameter read tool, the description is adequate but not complete. It does not explain what is returned (e.g., raw text, base64) or any side effects. Given the lack of an output schema and annotations, more detail would be expected to fully inform the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for both parameters, each with a clear description. The tool description adds no additional meaning to the parameters, 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 'read' and the resource 'a text file out of a persistent Linux machine.' It distinguishes itself from siblings like scalix_computer_write_file and scalix_computer_exec, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives such as scalix_computer_exec (which could read files via cat) or scalix_computer_write_file. The usage context is only implied by the tool's name and basic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_computer_set_ssh_keysAInspectReplace the ssh keys authorised for root on a persistent Linux machine. This is how you revoke: send the list without the key you want gone, and on a running machine it stops working immediately. Sending an empty list removes every key. Not a patch — whatever you send becomes the whole list, so read the current keys from scalix_computer_list first if you mean to add one.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Machine id | |
| ssh_keys | Yes | The complete list of OpenSSH public keys, max 32. Empty array removes all of them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation replaces the entire list, that revocation takes effect immediately on a running machine, and that an empty list removes all keys. This goes beyond the schema, revealing the key behavioral nuance of replacement vs patching.
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, tightly packed with actionable information: what the tool does, how to revoke, and how to add without clobbering. No filler words 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 2-parameter tool with no output schema and no annotations, the description covers the essential behavioral aspects: the replace semantics, immediate effect, and prerequisite read. It leaves little ambiguity for an agent selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage, including 'complete list' and 'empty array removes all.' The description reinforces these semantics but does not add new parameter-level meaning, 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 opens with 'Replace the ssh keys authorised for root on a persistent Linux machine,' clearly identifying the verb (replace), resource (ssh keys for root), and context (persistent Linux machine). This distinguishes it from sibling tools like scalix_computer_exec, scalix_computer_read_file, and scalix_computer_write_file, none of which manage SSH keys.
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 explains the revoke workflow ('send the list without the key you want gone') and the addition workflow ('read the current keys from scalix_computer_list first if you mean to add one'). It also warns about the non-patch behavior, clearly telling the agent when to use the read tool first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_computer_startAInspectStart a stopped persistent Linux machine. Same disk, same address.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Machine id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It discloses a key behavior ('Same disk, same address') indicating state persistence, but does not mention potential error conditions (e.g., already running), startup time, or idempotency. It adds some value but lacks richer operational detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero wasted words. The key action and the most important behavioral fact are front-loaded, making it immediately scannable and easy for an agent to parse.
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 tool with one parameter and no output schema, the description is largely complete: it states the action, the target state ('stopped'), and the persistence guarantee. It could optionally mention failure modes or prerequisites, but given the low complexity, the description covers the essential context 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 schema fully describes the single parameter 'id' with 'Machine id', so the baseline is 3. The description adds no additional parameter-specific semantics beyond what the schema already provides, though the resource context ('Linux machine') implicitly relates to the id. This is acceptable given the schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start') and the specific resource ('a stopped persistent Linux machine'). It distinguishes from siblings like scalix_computer_create (which creates new machines) by emphasizing it starts an existing stopped machine, and 'Same disk, same address' clarifies the persistence aspect.
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 starting machines that were previously stopped and persistent, which gives clear context for when to use it. It does not explicitly exclude alternatives or mention when not to use it, but the 'stopped persistent' qualifier effectively guides selection relative to create/stop/delete siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_computer_stopAInspectStop a persistent Linux machine. The disk and the network address are kept, so starting it again returns the same files at the same address. Stop machines you are done with — a stopped machine costs only its disk.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Machine id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses persistence semantics (same files and address on restart) and cost implications, which are key behavioral traits beyond just 'stop'. It doesn't mention authorization or edge cases, but the core behavior is well conveyed.
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: the first states the action, the second adds behavioral detail and a usage cue. It is front-loaded and every clause contributes information, earning a high score.
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 stop operation with no output schema, the description covers the action, persistence consequences, and cost. It doesn't cover edge cases or error conditions, but given the tool's simplicity, it is largely 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?
The input schema defines the single `id` parameter with a 'Machine id' description, giving 100% schema coverage. The description adds no parameter semantics beyond what the schema already provides, 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 opens with a specific verb+resource: 'Stop a persistent Linux machine.' It clarifies the key distinction from deletion by stating disk and network address are kept, which differentiates it from sibling scalix_computer_delete.
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 says 'Stop machines you are done with' and adds cost context ('a stopped machine costs only its disk'), giving clear when-to-use guidance. It doesn't explicitly name alternatives like delete or start, but the context implies when stopping is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_computer_write_fileAInspectWrite a text file into a persistent Linux machine. Use this instead of shelling out with cat/echo — no quoting to get wrong.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Machine id | |
| mode | No | Unix mode in decimal, e.g. 493 for 0755. Omit unless the file must be executable. | |
| path | Yes | Absolute path inside the machine, e.g. /root/app/main.py | |
| content | Yes | File contents as text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the file is written to a persistent Linux machine and highlights the quoting safety, but does not mention overwrite semantics, permission requirements, or potential side effects. It is adequate but lacks depth for a write 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?
Two concise sentences with no filler. The main purpose and key usage guidance are front-loaded, making the description efficient and easy to parse.
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 write tool with a fully described schema, the description provides sufficient context: what it does, when to use it, and the target environment. It does not cover return values or error cases, but given the simplicity of the tool 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 100%, so parameters are already well-documented. The description adds the context that content can be supplied without quoting concerns, but does not add further parameter-level meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Write') and a clear resource ('text file into a persistent Linux machine'). It distinguishes itself from shelling out with cat/echo and from sibling tools like scalix_computer_read_file.
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 instructs when to use this tool ('Use this instead of shelling out with cat/echo') and gives a rationale ('no quoting to get wrong'). This is clear, actionable guidance for an agent choosing between approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_compute_scaleAInspectCOMING SOON — not available yet. Container deployments are not built yet; this returns 501. Scale a Scalix Run service with scalix_run_scale instead.
| Name | Required | Description | Default |
|---|---|---|---|
| replicas | Yes | Target replica count | |
| deployment_id | Yes | Deployment ID to scale |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the behavior: it returns a 501 error and is non-functional. This is complete transparency for a placeholder tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the critical status 'COMING SOON', no wasted words. Every sentence serves a clear purpose.
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 non-functional tool with no output schema, the description is complete: it explains the current state, expected error, and correct alternative. No additional context needed.
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 has 100% coverage for both parameters (deployment_id, replicas). Description adds minimal meaning beyond schema—just mentions scaling a Scalix Run service, which parallels the parameter names. Baseline 3 is appropriate as description does not significantly enhance schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states this tool is 'COMING SOON — not available yet' and returns a 501 error. It specifies the verb 'scale' and resource 'Scalix Compute' but directs to the correct sibling tool scalix_run_scale. Purpose is unambiguous and distinguishes from the functional alternative.
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 tells when not to use the tool ('not available yet') and provides a direct alternative: 'Scale a Scalix Run service with scalix_run_scale instead.' No room for misinterpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_cron_createBInspectCreate a cron schedule to run a function or webhook on a timer.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Schedule name | |
| config | No | Action configuration (function_id or webhook URL) | |
| expression | Yes | Cron expression (e.g., '*/5 * * * *') | |
| action_type | Yes | Type of action to trigger |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only states the basic action without mentioning side effects (e.g., whether duplicate names are allowed), idempotency, or error cases. The description is too brief for a mutation 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 single sentence that immediately conveys the core purpose. No superfluous words or 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?
Given the tool has four parameters (including a nested object) and no output schema or annotations, the description is insufficient. It does not explain return values, error states, or how to modify/delete schedules, leaving significant gaps for an agent.
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% with each parameter having a description. The tool description does not add additional meaning beyond the schema. The nested 'config' parameter is described minimally in the schema; the description could have elaborated on its structure.
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 creates a cron schedule to run a function or webhook on a timer. The action verb 'create' and resource 'cron schedule' are specific. Among sibling tools, none have similar functionality (e.g., scalix_fn_invoke triggers functions, not schedules), so it is well-distinguished.
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 provided on when to use this tool versus alternatives, prerequisites, or limitations. For example, it does not mention whether cron schedules can be created for existing functions/webhooks or any constraints on expressions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_db_branch_createAInspectCreate an isolated ScalixNova database branch (instant copy-on-write sandbox) for safe experimentation — run queries and migrations against it without touching production data. Returns a scoped token for the branch; drop it with scalix_db_branch_drop or let the TTL expire.
| Name | Required | Description | Default |
|---|---|---|---|
| ttl_seconds | No | Time-to-live in seconds (default: 3600) | |
| access_level | No | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: instant copy-on-write sandbox, no production data impact, returns a scoped token, and lifecycle management (drop or TTL). No annotations are provided, so the description carries the full burden and does a good job.
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 long, front-loaded with the core action, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value (scoped token) and lifecycle, but lacks details on limitations or quotas. Given no output schema, it adequately covers the essential aspects for a create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the parameters (ttl_seconds, access_level) despite schema description coverage being only 50% according to context. The schema already describes the parameters, but the description fails to add any additional meaning or guidance on their usage.
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 creates an isolated database branch for safe experimentation, using specific verbs and resources. It distinguishes itself from siblings by mentioning the corresponding drop tool.
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 states when to use the tool ('for safe experimentation') and provides alternatives: dropping the branch with scalix_db_branch_drop or letting the TTL expire.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_db_branch_dropAInspectDrop a database branch created with scalix_db_branch_create and revoke its token.
| Name | Required | Description | Default |
|---|---|---|---|
| sandbox_id | Yes | Branch (sandbox) ID to drop |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the destructive nature (drop) and the token revocation, but does not disclose whether the action is reversible, any permission requirements, or potential side effects. Since no annotations are provided, the description carries the full burden, which is only partially 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?
The description is a single sentence with 13 words, front-loading the action and resource. Every word is necessary, and there is no extraneous 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?
Given the simplicity of the tool (one parameter, no output schema), the description adequately explains the main effect (drop and revoke token). It lacks only minor details such as return value or error handling, but for a straightforward deletion operation, it is reasonably 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?
The schema has 100% coverage with a clear description for the single parameter sandbox_id. The tool description does not add additional semantic meaning beyond what is already in the schema, so the baseline score 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 action 'Drop' and the resource 'database branch', with an additional side effect 'revoke its token'. It distinguishes itself from the sibling tool scalix_db_branch_create by referencing it as the counterpart.
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 that the tool is used after scalix_db_branch_create to destroy the branch, but it does not explicitly state when to use or when not to use it, nor does it mention any alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_db_migrateCInspectApply a database migration by version number.
| Name | Required | Description | Default |
|---|---|---|---|
| version | Yes | Migration version to apply | |
| tenant_id | Yes | Tenant ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states a mutation ('apply migration'), but fails to mention side effects (e.g., schema changes, reversibility, required permissions, or failure behavior). This is insufficient for a potentially destructive operation, especially without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action ('Apply a database migration by version number'). Every word carries meaning with no redundancy or filler. Ideal for quick understanding.
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 is no output schema and the tool involves a complex operation (database migration), the description is too brief. It omits details about return values, idempotency, environment applicability, or post-migration state. The high sibling count and lack of annotations further demand richer 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?
Schema coverage is 100%, with both parameters (version, tenant_id) having descriptions. The tool description adds no extra context about parameter formats, constraints, or relationships beyond what the schema provides. Baseline of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('apply') and resource ('database migration by version number'), clearly indicating the tool's function. It distinguishes from sibling database tools like scalix_db_query or scalix_db_optimize, which serve different purposes. However, it could be slightly more specific about the scope (e.g., applying pending migrations) to fully differentiate.
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 no guidance on when to use this tool versus alternatives like scalix_db_branch_create or scalix_db_optimize. It does not mention prerequisites, use cases, or scenarios where this tool is or isn't appropriate, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_db_optimizeAInspectAnalyze a SQL query and return optimization suggestions including index recommendations and query rewrites.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to analyze and optimize |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the tool returns optimization suggestions (index recommendations, query rewrites), implying a read-only analysis with no side effects. Missing explicit mention of auth requirements or limits, but acceptable given the straightforward nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that conveys all necessary information without any redundant words 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 tool with one parameter and no output schema, the description adequately explains the return value (optimization suggestions). No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats the schema's parameter description ('SQL query to analyze and optimize') without adding additional format, length, or usage details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it analyzes a SQL query and returns optimization suggestions including index recommendations and query rewrites. The verb 'analyze' and resource 'SQL query' are specific, and it effectively distinguishes itself from sibling tools like scalix_db_query or scalix_db_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?
No explicit when to use or when not to use, nor mention of alternatives. The purpose is clear enough for an agent to infer usage, but there is no guidance on contrasting with other DB tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_db_piiAInspectList all columns classified as containing personally identifiable information (PII).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read-only list operation, but lacks details such as whether permissions are required, if there are limits on output, or what 'classified' means. The description is basic but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. It is appropriately sized and front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is minimal. It conveys the core purpose but omits context like output format (list of column names or details), prerequisites (database connection), and what 'classified' entails. Some additional detail would improve 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?
There are zero parameters, so the baseline is 4. The description does not add parameter semantics because none exist. Schema coverage is 100% (no params to describe).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists columns containing PII, which is a specific verb and resource. It distinguishes from sibling tools like scalix_db_schema (lists all columns) and scalix_db_search_columns (search by criteria) by focusing on PII classification.
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 on when to use this tool versus alternatives. For example, it does not mention that this tool is for PII-only listing, while other tools like scalix_db_schema or scalix_db_search_columns could be used for general column information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_db_queryAInspectExecute a SQL query against the project database. Returns columns, rows, row count, and cost breakdown. Destructive statements (DROP/TRUNCATE/bulk DELETE) require a two-step confirmation: the first call returns code CONFIRMATION_REQUIRED with a confirmation_token — re-call with that value in confirm_token to execute.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to execute | |
| params | No | Bind parameters for the query | |
| confirm_token | No | Confirmation token from a prior CONFIRMATION_REQUIRED response; required to execute destructive SQL (single-use, short TTL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses destructive behavior requires confirmation, return structure (columns, rows, row count, cost), and the confirmation token mechanism. Missing details on error handling, rate limits, or role requirements, but sufficient for typical use.
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 clear, front-loaded sentences. First defines purpose and output; second details the critical destructive confirmation flow. No 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?
Given no output schema, the description explains return fields. The destructive confirmation process is fully detailed. Lacks mention of cost breakdown specifics or advanced features like pagination, but complete for a query execution tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value for confirm_token by explaining its origin (from prior CONFIRMATION_REQUIRED) and its single-use, short TTL nature. SQL and params are adequately described, but no extra syntax or formatting 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 clearly states the tool executes SQL queries against the project database. It distinguishes itself from sibling database tools (e.g., scalix_db_schema, scalix_db_migrate) by focusing on arbitrary queries and return 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 explains the two-step confirmation for destructive statements, which guides safe usage. However, it does not explicitly compare to alternatives like scalix_db_schema for schema exploration or scalix_db_table for table-specific queries, though context implies it's for ad-hoc queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_db_relationshipsAInspectGet the relationship map showing how tables are connected via foreign keys.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions the output is a relationship map but does not disclose any potential performance implications, authentication requirements, or return format. Minimal transparency beyond the core function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the tool's purpose without any extraneous information. It is optimally concise.
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 absence of an output schema and annotations, the description is adequate but could be more complete by specifying the exact format or structure of the relationship map. It covers the essential purpose but leaves some ambiguity for an agent.
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 no parameters, so the input schema provides no information. The description does not need to add parameter semantics, and the baseline score for zero parameters is 4.
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 specific verb 'Get' and resource 'relationship map', and distinguishes it from sibling tools like scalix_db_schema by focusing specifically on tables connected via foreign keys.
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 understanding foreign key connections but does not explicitly state when to use this tool versus alternatives like scalix_db_schema or scalix_db_table, nor does it provide any when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_db_schemaAInspectGet the full database schema including all tables, columns, types, and relationships.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should disclose behavioral traits. It states what is returned but omits side effects, permissions, cost, caching, or limitations. For a read-only tool, a brief note about safety would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the purpose. No extra words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description adequately explains the tool's purpose and output scope. Minor omission: could mention whether it includes views or indexes, but still largely 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?
There are no parameters, so schema coverage is 100%. The description adds meaning by specifying the output includes 'all tables, columns, types, and relationships', which is not evident from the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'full database schema', and enumerates contents (tables, columns, types, relationships). It distinguishes from siblings like scalix_db_table (which likely gets a single table) by emphasizing 'full'.
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 provided on when to use this tool versus alternatives (e.g., scalix_db_table, scalix_db_relationships). There is no mention of prerequisites, context for use, or typical workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_db_search_columnsBInspectSearch for columns by name or type across all tables.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term to match column names or types |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It fails to disclose important behavioral details such as whether the search is exact match or pattern-based, if case-sensitive, or how results are returned (e.g., list of column names and tables).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool with no output schema, the description is minimally adequate. However, it lacks details on search semantics (e.g., wildcards, case sensitivity) and result format, which would improve 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 100% for the single parameter 'query', and the tool description essentially repeats the same meaning: 'Search term to match column names or types'. No additional parameter insight is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search for columns' and the resource 'across all tables', distinguishing it from siblings like scalix_db_query (query data) and scalix_db_schema (show schema). It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The use case is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_db_tableAInspectGet detailed information about a specific database table including columns, indexes, and foreign keys.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table name to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states what the tool returns but does not disclose behavioral traits like side effects (likely none), authentication requirements, performance implications, or whether it is read-only. The 'Get' verb hints at read-only, but not explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and resource, directly lists what is included. No 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 single-parameter introspection tool, the description adequately covers the output scope (columns, indexes, foreign keys). No output schema, but the description provides sufficient context. Missing guidance on prerequisites or return format, but not critical.
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?
Only one parameter (table) with schema description 'Table name to inspect'. The description adds no extra semantics beyond the schema. Schema coverage is 100%, so baseline 3 applies; no additional value provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get', the resource 'detailed information about a specific database table', and enumerates the specific aspects covered (columns, indexes, foreign keys). It is distinct from sibling tools like scalix_db_schema (schema-wide) and scalix_db_query (query execution).
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 on when to use this tool vs alternatives such as scalix_db_schema or scalix_db_relationships. The description implies usage for table metadata inspection but lacks explicit context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_db_text_to_sqlAInspectTranslate a plain-language question into a candidate SQL query using pattern-matching against the live schema (no AI model — simple questions only: counts, averages, filtered selects on a named table). Returns the SQL without executing it, with a confidence score; low confidence means the table was guessed. Review the statement and tables_used, then run it with scalix_db_query. For complex questions, read scalix_db_schema and write the SQL directly.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The question to answer from the database, in plain language (e.g. 'how many orders shipped last week?') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: no AI model, does not execute SQL, returns confidence score, and explains low confidence meaning. It could mention error cases (e.g., unmatched schema), but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then provides necessary behavioral and usage details. At four sentences, it is slightly long but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers output structure (SQL, tables_used, confidence) and refers to sibling tool for execution. It also addresses boundary conditions (simple vs complex) making it 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?
The one parameter 'question' is fully described in schema. The description adds context on acceptable question types (counts, averages, filtered selects), which helps the agent formulate valid inputs.
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 translates plain-language to SQL using pattern-matching (not AI), specifies the types of simple questions handled, and distinguishes it from executing or reading schema. It names the action and resource precisely.
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 tells when to use (simple questions) and when not to (complex questions: use scalix_db_schema instead). It also instructs to review and then execute with scalix_db_query, providing clear workflow guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_domain_addBInspectAdd a custom domain to the project. Returns DNS records to configure.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name to add (e.g., api.example.com) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it returns DNS records but does not disclose idempotency, error behavior (e.g., duplicate domain), or auth requirements. Insufficient for a mutation 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?
Single, clear sentence front-loaded with action and return value. No redundant words, but could be slightly more informative without losing conciseness.
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 simplicity (1 param, no output schema), description covers core action and return but omits error scenarios and whether operation is reversible. Adequate but not comprehensive.
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% for the single parameter. Description adds no additional semantic value beyond the schema example; 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?
Description clearly states verb 'Add', resource 'custom domain to project', and return value 'DNS records'. Unambiguous purpose that distinguishes from sibling tools like scalix_domain_list and scalix_domain_verify.
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 on when to use this tool vs alternatives. Sibling tools for listing and verifying domains exist but are not mentioned; no when-not-to-use or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_domain_listAInspectList all custom domains and their SSL/verification status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states the tool lists domains and their status. It does not disclose whether the operation is read-only, requires authentication, or any side effects.
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 waste, efficiently conveying the tool's purpose.
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 simplicity (no parameters, no output schema), the description adequately covers the return information. However, it could mention potential limitations or the scope 'all' implies no filtering, but overall is sufficiently 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?
There are zero parameters, so baseline is 4. The description adds meaning by specifying what is returned (domains and SSL/verification status), which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'custom domains' with the additional information of 'SSL/verification status', clearly distinguishing it from sibling tools like scalix_domain_add and scalix_domain_verify.
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 no guidance on when to use this tool versus alternatives such as scalix_domain_verify or scalix_domain_add, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_domain_verifyBInspectVerify DNS configuration for a custom domain and provision SSL certificate.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of conveying behavioral traits. It states the tool verifies DNS and provisions an SSL certificate, but does not disclose what specific DNS records are checked, what happens on failure, whether it modifies existing certificates, or if the operation is idempotent. For a tool that performs a stateful provisioning action, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence of 10 words that front-loads the key action ('Verify DNS configuration'). Every word is meaningful; there is no fluff 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 tool with a single required parameter and no output schema, the description is minimally adequate. It explains what the tool does but omits expected output (e.g., success/failure indication), potential side effects, and prerequisites. Given the simplicity, a score of 3 is appropriate—it is complete enough to use but leaves room for confusion.
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 ('domain'), and the input schema already provides a description: 'Domain to verify'. The tool description adds no additional detail beyond the schema. Given 100% schema coverage, the description meets the baseline of 3 but does not improve 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 purpose: 'Verify DNS configuration for a custom domain and provision SSL certificate.' It uses specific verbs ('Verify', 'provision') and identifies the resources ('DNS configuration', 'SSL certificate'). This distinguishes it from sibling tools like scalix_domain_add (which adds a domain) and scalix_domain_list (which lists domains).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., domain must be added first), nor does it indicate when not to use it. Sibling tools exist for adding or listing domains, but the description lacks context for choosing among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_events_publishAInspectPublish an event to a topic. Provide an event_type (a short name for the kind of event, e.g. 'user.created') and the data payload.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Event payload (JSON) | |
| topic_id | Yes | Topic ID to publish to | |
| event_type | Yes | Event type/name, e.g. 'user.created' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full burden of behavioral disclosure. It only states the basic action and parameter hints, omitting details like side effects, authorization needs, idempotency, or return values.
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, front-loaded with the purpose. Every part is necessary and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, a nested object, no output schema, and no annotations, the description adequately covers the main action and parameter hints but lacks details on behavior (e.g., synchronous vs fire-and-forget, constraints on topic_id).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining event_type with an example ('e.g. 'user.created'') and clarifying that data is the payload, which goes beyond the schema 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 clearly states the action ('Publish an event to a topic') with a specific verb and resource. It distinguishes itself from sibling tools like 'scalix_events_topics' which likely lists topics.
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 (publishing events) but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_events_topicsAInspectList the event-bus topics in the project, with each topic's ID and name. Use this to find or verify a topic_id before publishing with scalix_events_publish; publishing to a non-existent topic fails.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the listing behavior and return fields (ID, name), which provides adequate transparency for a simple read-only tool. No mention of pagination or limits, but for a list of topics this is acceptable.
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, no wasted words. Immediately conveys purpose and usage context. Front-loaded with action and result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters, the description is largely complete. It mentions the output fields. However, no output schema exists, so a bit more detail on return format would be helpful but not critical.
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?
Zero parameters, schema coverage 100%. Description does not need to add parameter semantics; baseline 4 is appropriate as there is no missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List the event-bus topics in the project, with each topic's ID and name.' This is a specific verb+resource, and it distinguishes from the sibling tool scalix_events_publish by providing context about its use as a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this to find or verify a topic_id before publishing with scalix_events_publish' and explains consequence: 'publishing to a non-existent topic fails'. Provides clear guidance without needing exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_fn_deployAInspectDeploy a Scalix Function — serverless, per-request billed, running in isolated microVMs — from a container image. Invoke it with scalix_fn_invoke once deployed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Function name | |
| image | Yes | Container image reference | |
| runtime | No | Runtime (e.g., nodejs20, python3.12) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds useful behavioral traits (serverless, per-request billed, isolated microVMs), but does not disclose important details such as whether the deployment is idempotent, what happens on conflict, or any auth requirements. This is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only two sentences that immediately state the purpose and a follow-up action. No unnecessary words or details, making it efficient for an AI agent to parse.
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 moderate complexity (3 parameters, no output schema), the description covers the core purpose and deployment model. It is missing some edge-case behavior (e.g., overwriting existing functions, rollback), but overall it provides sufficient context for typical usage.
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 has 100% coverage with descriptions for all three parameters. The tool description does not add any additional meaning or context beyond what is in the schema, so no extra value is provided.
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 deploys a Scalix Function, specifies it is serverless, per-request billed, and runs in isolated microVMs. It also mentions the follow-up invocation with scalix_fn_invoke, distinguishing it from sibling tools like scalix_fn_invoke and scalix_compute_deploy.
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 this tool (to deploy a serverless function) and hints at the next step (invoke with scalix_fn_invoke). However, it lacks explicit exclusions or comparisons with alternatives like scalix_compute_deploy, which could help differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_fn_invokeBInspectInvoke a deployed function with a JSON payload.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | JSON payload to pass to the function | |
| function_id | Yes | Function ID to invoke |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It fails to mention return values, error handling, asynchronicity, or side effects. For an invocation tool, details on output or empty response would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundant information, front-loaded verb and resource. Every word is necessary.
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 low complexity (2 parameters), the description omits important context: no mention of return values (no output schema), error scenarios, or behavior when function_id is missing. A complete description should at least hint at typical output.
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% with descriptions for both parameters. The description adds no extra context beyond the schema; it simply restates 'JSON payload' which aligns with the data parameter. Baseline 3 is appropriate as 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?
Description clearly states the action (invoke), resource (deployed function), and payload type (JSON). It distinguishes from sibling tools like scalix_fn_deploy and scalix_fn_list by specifying invocation rather than deployment or listing.
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 on when to use this tool versus alternatives, no prerequisites mentioned (e.g., function must be deployed), and no context on 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.
scalix_fn_listAInspectList all deployed serverless functions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It accurately indicates a read-only listing operation. However, it does not mention any potential pagination, limits, or return format, but given the simplicity and zero parameters, the behavior is largely self-evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It delivers complete information efficiently.
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 zero parameters, no output schema, and no annotations, the description is fully sufficient for a simple listing operation. It clearly states what the tool does without requiring additional 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?
There are no parameters, so the input schema is trivial with 100% coverage. The description does not need to add parameter information, and it appropriately omits irrelevant details. Baseline score for 0 parameters is 4.
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 'List all deployed serverless functions' clearly states the action (list) and the resource (deployed serverless functions). It effectively distinguishes from sibling tools like scalix_fn_deploy and scalix_fn_invoke.
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 provided on when to use this tool versus alternatives, nor are there any prerequisites or use case restrictions. The description simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_kv_getAInspectRead a single value from the project's key-value store by exact key. Returns the stored value, or a not-found error if the key does not exist or its TTL has expired. Use scalix_kv_list to discover keys by prefix first.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Exact key to look up (case-sensitive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns the stored value or a not-found error if the key does not exist or its TTL has expired. This is informative but lacks details on rate limits or authentication, which are not critical for a simple read. The behavior is well-described.
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: first explains the core action and result, second provides usage guidance. No unnecessary words, completely 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 read tool with one parameter and no output schema, the description covers all necessary aspects: what it reads, how to specify the key, what it returns, error conditions, and a pointer to a sibling for key discovery. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the key parameter as exact and case-sensitive. The description repeats 'exact key' and adds context about using scalix_kv_list, but does not add new semantic meaning for the parameter itself. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a single value from the project's key-value store by exact key. It distinguishes from sibling scalix_kv_list (discovers keys by prefix) and scalix_kv_set (writes), making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: use this tool when you know the exact key, and use scalix_kv_list to discover keys by prefix first. This helps the agent choose the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_kv_listAInspectList keys in the key-value store, optionally filtered by prefix.
| Name | Required | Description | Default |
|---|---|---|---|
| prefix | No | Filter keys by prefix |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states that it lists keys with optional prefix filtering, but does not mention scope (e.g., per project), ordering, pagination, or any potential impact like rate limiting. This is insufficient for an agent to fully understand side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly communicates the tool's purpose and optional parameter. It is front-loaded and contains no irrelevant 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 listing tool with no output schema, the description covers the basic function. However, it omits details like output format, pagination behavior, and error conditions, which are important for an agent to use it correctly without additional 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?
The input schema has 100% coverage for its single parameter, and the description adds 'optionally filtered by prefix' which repeats the schema. No additional meaning is added beyond what the 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 clearly states the verb 'List' and the resource 'keys in the key-value store', with an optional filter by prefix. This distinguishes it from sibling tools like scalix_kv_get (get a single key) and scalix_kv_set (set a key).
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 listing keys, optionally filtered, which provides clear context. However, it does not explicitly state when not to use or mention alternatives, though the sibling names make the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_kv_setBInspectSet a key-value pair with optional TTL.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key to set | |
| ttl | No | Time-to-live in seconds (0 = no expiry) | |
| value | Yes | Value to store |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It mentions mutation (Set) and optional TTL but omits critical details like overwrite behavior, authorization requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It could be slightly expanded without losing conciseness, but as is it's appropriately brief for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema), the description is mostly adequate but lacks mention of return value or confirmation behavior, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description only summarizes (e.g., 'optional TTL') without adding new 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 clearly states the verb 'Set' and the resource 'key-value pair with optional TTL', distinguishing it from sibling tools like scalix_kv_get and scalix_kv_list.
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 setting a key-value pair but provides no explicit guidance on when to use this tool versus other KV tools or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_project_createAInspectCreate a new project within an organization. Returns the project ID and API credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Project display name | |
| slug | Yes | URL-safe project slug | |
| org_id | Yes | Organization ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only notes return of project ID and API credentials. Does not disclose side effects, permissions needed, or state changes beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, concise sentence that front-loads the action and result. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately describes creation and return value but lacks details on uniqueness constraints, error handling, or relationship to other project tools.
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 covers all parameters with descriptions (100% coverage). Description adds no extra semantic information beyond what 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?
Description clearly states verb 'Create' and resource 'project within an organization', distinguishing it from siblings like scalix_project_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when or when not to use, nor alternative tools. Usage is implied by the action, but lacks context like prerequisites or conflicts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_project_listAInspectList every project in an organization, with each project's ID, name, and slug. Use this to resolve a project ID before calling project-scoped tools. Requires admin scope on the organization.
| Name | Required | Description | Default |
|---|---|---|---|
| org_id | Yes | Organization ID whose projects to list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool lists all projects and returns ID, name, and slug, but lacks details on pagination, rate limits, or potential side effects. For a simple list tool, 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?
The description is two sentences long, with the first sentence stating the core purpose and the second providing usage context. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is complete. It covers what the tool does, what it returns, its typical use case, and required permissions. No gaps for an agent to interpret.
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% with only one parameter (org_id), and the schema already describes it as 'Organization ID whose projects to list'. The description does not add extra meaning beyond that, so 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 resource 'every project in an organization', specifying the returned fields (ID, name, slug). It also differentiates its use case by mentioning it helps resolve a project ID before calling project-scoped tools, distinguishing it from sibling tools like scalix_project_create.
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 resolve a project ID before calling project-scoped tools' and notes 'Requires admin scope on the organization.' This provides clear when-to-use and prerequisite information, though it does not explicitly 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.
scalix_run_deployAInspectDeploy a long-running container service on Scalix Run from a container image. Creates a new service, or a new revision of an existing service with the same name, with health checks, a public HTTPS URL, and autoscaling between min_instances and max_instances (min 0 = scale-to-zero when idle). Billed per vCPU-hour while instances run. Roll back a bad revision with scalix_run_rollback.
| Name | Required | Description | Default |
|---|---|---|---|
| env | No | Environment variables as key-value pairs | |
| name | Yes | Service name | |
| port | No | Port the container listens on | |
| image | Yes | Container image from the Scalix registry ({registry}/{project_id}/{repo}:{tag}). External registries (Docker Hub, etc.) are NOT supported — build & push first with scalix_build_create. | |
| max_instances | No | Maximum instances | |
| min_instances | No | Minimum instances (0 = scale to zero) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses health checks, public HTTPS URL, autoscaling between min/max instances, scale-to-zero, and billing per vCPU-hour. However, it omits details on deployment failure behavior and permission requirements.
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 plus a rollback note, concise and front-loaded with the main action. It could use structure like bullet points, but overall it is clear and not verbose.
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?
No output schema exists, and the description does not mention return values or deployment status. For a deployment tool, this is a gap, though sibling tools (scalix_run_list) cover status. The description adequately covers core behavior.
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 100% schema coverage, baseline is 3. The description adds context for min_instances (scale-to-zero) and autoscaling, but other parameters like env and port lack additional explanation beyond their schema 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 specifies 'Deploy a long-running container service on Scalix Run from a container image.' It clearly differentiates from siblings like scalix_fn_deploy (functions) and scalix_compute_deploy (VMs) by focusing on long-running containers, and references scalix_run_rollback for rollback.
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 states when to use: creating a new service or updating an existing one. It mentions rollback via scalix_run_rollback, but does not explicitly exclude other tools or provide alternative selection criteria. Still, it gives sufficient context for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_run_listAInspectList all deployed container services in the project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It correctly implies a read-only operation ('List') but does not disclose any permissions, rate limits, or potential side effects. Minimal but sufficient for a simple list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste, immediately conveys the core purpose. Ideal length for a no-param tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of return format or what constitutes a 'deployed container service'. Without an output schema, the agent may not know what data to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline applies. The description adds no parameter information, which is acceptable given 100% schema coverage and zero 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 states the action (List) and resource (deployed container services in the project), distinguishing it from sibling list tools like scalix_compute_list and scalix_fn_list.
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 on when to use this tool versus alternatives like scalix_compute_list or scalix_kv_list. The description only states the function without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_run_rollbackAInspectRoll a Scalix Run service back to an earlier revision — omit 'revision' to return to the immediately previous one. Traffic switches to the target revision; the replaced revision is kept and can be redeployed later. Use scalix_run_list to see services and their current revisions.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Service ID (from scalix_run_list) | |
| revision | No | Revision number to roll back to; omit for the immediately previous revision |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that traffic switches to the target revision and the replaced revision is kept and can be redeployed later, indicating non-destructive 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 two sentences with no wasted words. The first sentence delivers the core purpose and parameter nuance, and the second provides a cross-reference to a related tool. It is front-loaded and 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?
For a straightforward rollback operation, the description covers the essential aspects: purpose, parameter behavior, side effects, and prerequisite. The absence of an output schema is acceptable as the tool performs an action rather than returning data.
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 describes both parameters, but the description adds meaning by explaining that omitting revision rolls back to the immediately previous one, and that the id comes from scalix_run_list. This goes beyond the schema definitions.
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 ('roll back'), the resource ('Scalix Run service'), and distinguishes from siblings by specifying the context of revising deployments. It explicitly mentions the optional parameter behavior and references scalix_run_list for listing services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool and mentions the prerequisite of using scalix_run_list to see services and revisions. It explains the optional parameter use case but does not explicitly state when not 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.
scalix_run_scaleAInspectChange the autoscaling bounds of an existing Scalix Run service without redeploying it. Raising min_instances keeps instances warm (no cold starts, higher cost); min_instances 0 enables scale-to-zero when idle. Takes effect immediately. Find service IDs with scalix_run_list.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Service ID (from scalix_run_list) | |
| max_instances | No | New maximum instance count the service may scale up to | |
| min_instances | No | New minimum instance count (0 = scale-to-zero when idle) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that changes take effect immediately and explains behavioral aspects of min_instances (warm instances, cost, scale-to-zero). However, it lacks details on safety, permissions, or potential side effects (e.g., what happens when scaling down). Without annotations, more behavioral context would be beneficial.
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 with three sentences. The first sentence clearly states purpose, the second adds useful parameter detail, and the third provides immediate effect and how to find IDs. No redundant information, well-structured.
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 lack of output schema and annotations, the description adequately covers the tool's action, parameters, and side effects. It references the needed companion tool. It could mention if there is any confirmation or return value, but overall it provides sufficient context for an AI 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 input schema already has 100% coverage with descriptions for all three parameters. The description adds extra value by explaining the trade-offs of min_instances (warm vs scale-to-zero) and referencing the sibling list tool for id, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Change' and the resource 'autoscaling bounds of an existing Scalix Run service,' distinguishing it from redeploy. It also specifies the context (existing service) and the effect (immediate), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use this tool (instead of redeploying) and explains the implications of min_instances values (warm instances vs scale-to-zero). It also tells where to find service IDs (scalix_run_list). It could be improved by explicitly stating when not to use it (e.g., for scaling other resources), but overall adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_sandbox_runBInspectExecute code in an isolated sandbox. Supports Python, JavaScript, TypeScript, and Bash. Returns stdout/stderr.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Source code to execute | |
| files | No | Additional files (filename -> content) | |
| language | Yes | Programming language | |
| packages | No | Packages to install (pip/npm) | |
| timeout_seconds | No | Max execution time in seconds (default: 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It mentions returning stdout/stderr but omits important details like sandbox lifecycle, network access, file system persistence, exit codes, or security restrictions.
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 focused sentences with front-loaded purpose. Every word adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters including nested objects and no output schema, the description is adequate but lacks details on return format structure, error handling, and side effects. For a sandbox tool, more context on execution environment is expected.
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 provides full descriptions for all 5 parameters. The description adds no additional meaning beyond the schema, so 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?
Clearly states 'Execute code in an isolated sandbox' and lists supported languages. However, it does not explicitly differentiate from siblings like scalix_fn_invoke or scalix_run_deploy, leaving some ambiguity.
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 on when to use this tool vs. alternatives. It does not mention prerequisites, limitations, or scenarios where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_searchAInspectSearch the Scalix original-source index — a curated set of original publishers (newsrooms, wires, regulators), not the open web. Returns originals only by default (syndicated copies collapsed to the source that published first), with provenance: source, published date, region, and canonical flag.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query | |
| limit | No | Max results (1-100) | |
| region | No | Filter by region, e.g. 'in', 'eu', 'us', 'global' | |
| language | No | Filter by language code, e.g. 'en' | |
| original_only | No | Return only canonical originals (default true); set false to see all syndicated copies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: it returns only originals by default, collapses syndicated copies to the first publisher, and provides provenance fields. It does not explicitly state whether the tool is read-only, but the read-heavy nature is implied. Additional details like error handling or rate limits are absent.
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 tight two-sentence paragraph with no fluff. The first sentence defines the core purpose and scope; the second adds behavioral details. Every word 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?
Without an output schema, the description covers return fields (source, published date, region, canonical flag). However, it omits details like pagination, result count, or error responses. Overall, it provides sufficient context for basic use but could be more 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?
All 5 parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds context by framing the search as returning original sources, but does not significantly expand on individual parameter meanings beyond the schema. The 'original_only' parameter behavior is reiterated from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches a curated original-source index, distinguishing it from open web search. It specifies the dataset scope (original publishers) and default behavior (returns originals only). This is highly specific and differentiates from sibling tools like scalix_db_query.
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 use when original source content is needed, contrasting with general web search. However, it does not explicitly list when not to use or mention alternative sibling tools. The context is clear but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_statusAInspectGet the current health status of the Scalix Cloud platform including all service components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Get the current health status' implying a read-only operation, but it omits details about output format, caching, rate limits, or authentication requirements.
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 wasted words. It efficiently conveys the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is adequate but not rich. It could be improved by hinting at the output structure (e.g., 'returns JSON with overall and per-component status').
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 are no parameters, so schema description coverage is trivially 100%. The description adds context by specifying what the tool returns (health status including service components), which fulfills the baseline for 0-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current health status of the Scalix Cloud platform', distinguishing it from sibling tools that target specific services or 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 checking overall platform health, but it does not explicitly mention when to use this tool versus alternatives or provide exclusions. No competing tool exists among siblings, but guidance is still implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_storage_create_bucketAInspectCreate a new Scalix Storage bucket in the project (S3-compatible object storage). Bucket names must be unique within the project. Setting public=true makes every object in the bucket readable without authentication — leave it false (the default) and use presigned URLs for private sharing.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Bucket name, unique within the project | |
| public | No | true = all objects publicly readable without auth; false (default) = private, share via presigned URLs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that public buckets allow unauthenticated reads and the default is private. It mentions uniqueness but omits potential side effects like latency or cost.
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 that front-load the primary action. Every sentence adds value without redundancy. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers purpose, parameter usage, and behavioral expectations adequately. No information gaps are apparent.
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% with descriptions, but the description adds context by explaining the trade-off between public and private sharing. This goes beyond the schema's basic 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 clearly states the tool creates a Scalix Storage bucket, specifying the resource and action. It mentions S3-compatibility and uniqueness, and distinguishes itself from sibling storage tools like list, download, upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on bucket name uniqueness and explains when to set public=true vs false (private with presigned URLs). This helps the agent choose appropriate parameter values. However, it does not explicitly state when to avoid using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_storage_downloadAInspectDownload an object from storage. Returns the content as base64.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Object key (path) | |
| bucket | Yes | Bucket name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the return is base64, which is a key behavioral trait. However, it does not mention other aspects like size limits, error handling, or authentication needs, which could be valuable for a download 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 extremely concise with two sentences: the first states the purpose, the second adds the return format. No unnecessary words or information, making it easy 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 there is no output schema, the description mentions the return format (base64) but lacks other context such as what happens on errors (e.g., missing object), whether it streams, or if there are size limits. It partially fulfills completeness but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions, achieving 100% coverage. The description does not add additional meaning beyond what the schema provides, 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 action ('Download an object from storage') and specifies the return format ('content as base64'). It differentiates well from sibling tools like scalix_storage_list, scalix_storage_create_bucket, and scalix_storage_upload, which have distinct purposes.
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 usage scenario (retrieving an object), but does not provide explicit guidance on when to use it versus alternatives, nor are there any exclusions or prerequisites mentioned. The context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_storage_listAInspectList storage buckets, or list objects in a specific bucket with optional prefix filter.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket | No | Bucket name. If omitted, lists all buckets. | |
| prefix | No | Filter objects by key prefix |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool lists buckets or objects with optional prefix filtering, but does not mention side effects, permissions, rate limits, or return format. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that captures the tool's core functionality without any wasted words. It is concise and to the point.
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 no output schema and a simple list operation, the description sufficiently conveys what the tool does and the role of parameters. It could mention the return format, but is otherwise complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds context by noting the optional prefix filter and the bucket omission behavior. However, it largely restates schema info, so the added value is modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing storage buckets or objects in a bucket with an optional prefix filter. It distinguishes itself from siblings like scalix_storage_create_bucket, scalix_storage_download, etc., which have different actions.
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 scenarios (listing storage resources) but does not explicitly provide when to use this tool versus alternatives, nor does it mention when not to use it. No exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_storage_uploadBInspectUpload content to object storage. Provide the content as a base64-encoded string.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Object key (path) | |
| bucket | Yes | Target bucket name | |
| content | Yes | Base64-encoded file content | |
| content_type | No | MIME type | application/octet-stream |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only states it uploads content but does not disclose whether it overwrites existing objects, size limits, authentication needs, or response behavior. The description lacks critical behavioral 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?
The description is extremely concise with two sentences, no redundant information, and front-loaded with the core action. 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 write operation with no output schema and no annotations, the description is too minimal. It omits details like success/failure indicators, error handling, or any return value. The tool's complexity warrants more 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?
Schema description coverage is 100%, so the schema already documents each parameter adequately. The description adds minimal value by reiterating that content is base64-encoded, which is already in the schema. No additional semantics for key, bucket, or content_type.
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 'Upload content to object storage,' using a specific verb and resource. It distinguishes from siblings like scalix_storage_download and scalix_storage_list by focusing on uploading. The mention of base64 encoding adds specificity.
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 on when to use this tool versus alternatives like scalix_storage_create_bucket (if creating buckets is separate) or when not to use it. The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scalix_usageBInspectGet current usage metrics and costs for a project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID to check usage for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Get', implying read-only, but does not disclose authentication needs, potential delays, or whether it triggers any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundancy. It could be slightly more informative, but it avoids wordiness.
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 tool with one parameter, the description is adequate. However, without an output schema, it could explain what metrics and costs are returned (e.g., resources, time period) to be 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?
The schema already describes the single parameter well (100% coverage). The tool description adds the context that the usage metrics and costs are retrieved for that project, but does not add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('current usage metrics and costs'), and specifies the scope ('for a project'). Among sibling tools, none are about usage metrics, so it is well-differentiated.
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 provided on when to use this tool versus alternatives, prerequisites, or when not to use it. The agent must infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
Sign in to create a connector for this server.