CinderRoute Agent Exchange for public failed-build triage, artifact handoff, and remediation.
Scored across 8 tools
Each tool has a clearly distinct purpose: status, listing, logs, secrets, retry, command execution, and deploy. No two tools overlap in function; even the troubleshooting tools (read_build_logs vs run_build_command) are differentiated by reading vs executing.
All tools follow the consistent ci_ prefix with verb_noun pattern (get_build_status, list_failed_builds, read_build_logs, trigger_deploy). This uniformity makes the surface predictable and easy to navigate.
8 tools is well-scoped for a CI/CD server, covering the core lifecycle without bloat. Each tool addresses a distinct operational need, and the count feels neither thin nor excessive.
The set covers the primary CI workflows: inspecting builds, listing failures, reading logs, retrying, running diagnostic commands, and deploying. Minor gaps exist (e.g., no explicit build cancellation or deployment status listing), but these are likely secondary and can be worked around.
Inspect a CI build and receive its failed step and log cursor. Use read_build_logs next when status is failed.
| Name | Required | Description | Default |
|---|---|---|---|
| build_id | Yes | ||
| include_logs | No |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| build_id | Yes | |
| started_at | No | |
| finished_at | No | |
| observed_at | Yes | |
| repository_id | Yes | |
| duration_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds value by revealing key output concepts (failed step, log cursor) and prescribing the next action on failure, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The core purpose and output are stated first, and the conditional follow-up action is provided in the second sentence, making the description easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters and an output schema, so the description does not need to explain return values. However, it omits any explanation of the include_logs parameter and uses an imprecise sibling name, leaving minor but real gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for explaining parameters, but it does not explicitly explain build_id or include_logs. The mention of 'inspect a CI build' weakly implies build_id, but include_logs is completely unaddressed, leaving the agent without guidance on its effect.
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 ('Inspect') and resource ('a CI build'), and further clarifies what the tool returns: the failed step and log cursor. It distinguishes itself from siblings by pointing to a follow-up tool, though it refers to 'read_build_logs' rather than the exact sibling name 'ci_read_build_logs'.
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 explicit guidance to use read_build_logs next when the status is failed, which is a clear conditional routing to an alternative. It does not spell out when to prefer ci_list_failed_builds or when not to call this tool, but the main sequencing intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public read-only status feed; no bearer token is required. List active failed CI builds, then pass a returned build_id to get_build_status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| project | No |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| builds | Yes | |
| observed_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context: 'no bearer token is required' and 'active failed' filtering, plus the fact that the response contains build_id values to feed into get_build_status. This goes beyond the structured fields without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The first sentence front-loads the access model ('Public read-only...') and the second states the core action plus the follow-up workflow. No redundant phrasing or restating of the tool name.
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 an output schema, the description is nearly complete: it covers auth, scope, and next step. It doesn't explicitly explain how limit/project affect results, but these are self-evident from the schema. The safety profile is fully covered by annotations, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'limit' or 'project' parameters at all, and the input schema has 0% description coverage. The agent must rely on parameter names and constraints alone, with no guidance on how project filtering or limit pagination affects the list. Description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'List active failed CI builds'. It also distinguishes itself from siblings by explicitly connecting to ci_get_build_status, making it clear this is the enumeration step for failed builds, not the status lookup or repository 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?
The description provides a clear usage pattern: list failed builds first, then pass a returned build_id to get_build_status. It also clarifies this is a public no-auth endpoint. It does not explicitly mention when to prefer ci_list_repositories, but the context is sufficiently directive for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List repositories and their latest build state. Failed builds include a build_id for get_build_status.
| Name | Required | Description | Default |
|---|---|---|---|
| org | No | cinderroute | |
| page | No | ||
| language | No | ||
| visibility | No |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| total | Yes | |
| observed_at | Yes | |
| repositories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so safety is covered without restating it. The description adds useful behavioral context beyond annotations: repositories are returned with their latest build state and failed builds expose a build_id intended for ci_get_build_status. Pagination or rate-limit details are not included, but the output schema helps cover return-shape expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the core action, and the second adds only the relevant build_id detail that helps the agent chain to ci_get_build_status.
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?
As a read-only list tool with an output schema and safety annotations, the description is serviceable at a high level. However, it leaves parameter semantics unexplained and does not route the agent between ci_list_repositories and ci_list_failed_builds, so the agent may not know how language/visibility filters or pagination affect results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter-level meaning: the org default, page pagination, language filter, and visibility enum are not explained in prose. The parameter names and defaults give some clues, but the description itself contributes nothing to understanding how these parameters affect the call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List repositories and their latest build state.' It also provides a downstream hint by noting failed builds include a build_id for ci_get_build_status, but it does not explicitly distinguish itself from ci_list_failed_builds, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance relative to alternatives. The phrase 'Failed builds include a build_id for get_build_status' implies a chaining path to ci_get_build_status, but the description does not tell the agent when to choose ci_list_repositories over ci_list_failed_builds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read bounded logs for a failed CI build. The result names the runner, workspace, and suggested diagnostic command.
| Name | Required | Description | Default |
|---|---|---|---|
| step | No | ||
| limit | No | ||
| build_id | Yes | ||
| log_cursor | No |
| Name | Required | Description |
|---|---|---|
| lines | Yes | |
| build_id | Yes | |
| truncated | Yes | |
| log_cursor | Yes | |
| observed_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety. It adds that logs are bounded and that the result names the runner, workspace, and a suggested diagnostic command, which is useful behavioral context. However, it does not disclose pagination or any limits on the log_cursor, so a 3 is appropriate given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words. The main action is front-loaded and the output hint is concise. It is efficient, though it could afford more detail without becoming 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?
For a 4-parameter tool with zero schema coverage, the description is incomplete. It explains the core purpose and some output, but omits all optional parameters (step, log_cursor) and any conditions on usage. The presence of an output schema helps, but the description still fails to give an agent enough information to invoke the tool correctly with the correct parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It mentions 'bounded' which relates to the limit parameter, but does not explain build_id, step, or log_cursor at all. No parameter names, formats, or constraints are given. This is a critical gap for a tool with 4 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?
States a specific verb (Read) and resource (bounded logs for a failed CI build), and hints at the output (runner, workspace, diagnostic command). The function is clear, but it does not explicitly contrast with sibling tools like ci_get_build_status or ci_list_failed_builds, so a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives. The phrase 'for a failed CI build' implies a condition, but does not explicitly state prerequisites or when to prefer this over ci_get_build_status or ci_run_build_command. No exclusions or alternative routes are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List masked deployment secret metadata for a project environment.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | ||
| project | Yes | ||
| environment | Yes |
| Name | Required | Description |
|---|---|---|
| project | Yes | |
| secrets | Yes | |
| environment | Yes | |
| observed_at | Yes | |
| values_exposed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable context beyond those annotations by specifying that secrets are 'masked' and that only 'metadata' is returned, not raw secret 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 a single front-loaded sentence with no filler. Every word contributes to identifying the operation, resource, and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Annotations and the presence of an output schema cover safety and return shape, and the core purpose is clear. However, the meaning of the optional 'key' parameter is missing, which is a meaningful gap given the small parameter surface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only restates project and environment without explaining their semantics and entirely omits the optional 'key' parameter. An agent cannot infer what 'key' does or when to provide 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 names a specific verb (List), a concrete resource (masked deployment secret metadata), and the scope (project environment). This clearly distinguishes it from siblings like ci_read_build_logs or ci_retry_build, leaving no doubt about what the tool operates on.
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 scope ('for a project environment') but does not explicitly state when to use this tool over alternatives or mention any exclusion criteria. Usage context is implied by the resource type rather than stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queue a retry after diagnostics. Defaults to dry-run and returns a retry build identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | ||
| build_id | Yes |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| dry_run | Yes | |
| build_id | Yes | |
| observed_at | Yes | |
| retry_build_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavior beyond annotations by mentioning dry-run defaulting and the return of a retry build identifier. Still, it does not clarify what dry_run=false does, whether actual side effects occur by default, or how a real retry is requested.
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 front-loads the core action and includes the most important behavioral detail, the dry-run default.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema present, the description is mostly sufficient, but it leaves ambiguity about the actual effect of dry_run and does not state prerequisites such as the build having failed or diagnostics being complete. An agent could infer most usage but not all side-effect nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It only echoes the dry-run default already present in the schema and gives no additional semantics for build_id or how dry_run changes execution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Queue'), the resource ('a retry'), and the context ('after diagnostics'). It is distinguishable from sibling tools because it uses 'retry' rather than 'get', 'list', 'read', 'run', or 'deploy', though it does not explicitly contrast with ci_run_build_command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear usage context: use this after diagnostics, and it defaults to dry-run, implying a safe preview mode. However, it does not explicitly state when not to use it or name alternative tools for actually running/deploying builds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a diagnostic command on an isolated CI runner and return bounded stdout and stderr for build troubleshooting. Pass the build_id returned by the incident tools to keep the investigation linked.
| Name | Required | Description | Default |
|---|---|---|---|
| shell | No | bash | |
| command | Yes | ||
| build_id | Yes | ||
| runner_id | No | ||
| timeout_seconds | No | ||
| working_directory | No | /workspace/api-gateway |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| stderr | No | |
| stdout | No | |
| build_id | Yes | |
| exit_code | Yes | |
| observed_at | Yes | |
| execution_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With destructiveHint=true already carrying the destructive warning, the description adds useful behavioral context: the runner is isolated and stdout/stderr are bounded. This tells the agent that output is capped and that execution is meant to be separate from production systems.
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 action and purpose, with no filler. The second sentence adds a practical linking hint without 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?
The tool has six parameters, no schema descriptions, and a destructive annotation; the description leaves parameter meaning and usage boundaries mostly implicit. It relies heavily on parameter names and output schema, making it incomplete for an arbitrary-command 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 description coverage is 0%, so the description must compensate. It only relates to build_id ('Pass the build_id') and command generically ('Execute a diagnostic command'); shell, runner_id, working_directory, and timeout_seconds are not addressed at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Execute a diagnostic command on an isolated CI runner') and states its purpose ('for build troubleshooting'). This clearly separates it from read-only siblings like ci_read_build_logs and from state-changing ones like ci_retry_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?
It gives clear context: use for build troubleshooting and pass the incident-related build_id to keep the investigation linked. It does not explicitly name alternatives or exclusions, but the troubleshooting framing plus 'isolated CI runner' makes the intended context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger a new deployment to the specified environment.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | main | |
| project | Yes | ||
| environment | Yes |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| queued_at | Yes | |
| observed_at | Yes | |
| deployment_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, so the destructive nature is known. The description adds that this is a new deployment to a specified environment, which aligns with the annotations and provides minimal extra context, but it does not disclose side effects such as whether it cancels existing deployments or requires special permissions.
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, direct sentence with no filler. It is appropriately short and front-loaded, though it could include more detail without becoming bloated.
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 destructive, non-idempotent operation, the description lacks critical context: what happens to the current environment, whether ref is required despite having a default, and how this differs from retrying a build. An output schema exists, but it does not compensate for missing usage and side-effect information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only references 'specified environment,' leaving project and ref semantics unexplained beyond the schema fields themselves. This is insufficient for a 3-parameter 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 clearly states the action (trigger) and resource (deployment) and ties it to a selected environment. It is distinct from siblings like ci_retry_build since it creates a new deployment rather than retrying a build, though it does not explicitly name that 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?
No guidance is provided about when to use this tool versus alternatives such as ci_retry_build or ci_run_build_command. The description implies use when a new deployment is needed, but it does not state prerequisites, exclusions, or how it compares to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
ci_get_build_status1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "build_id": {
+ "type": "string"
+ },
+ "duration_seconds": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "finished_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "observed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "repository_id": {
+ "type": "string"
+ },
+ "started_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "build_id",
+ "repository_id",
+ "status",
+ "observed_at"
+ ],
+ "type": "object"
+}ci_list_failed_builds1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "builds": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "observed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "total": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "builds",
+ "total",
+ "observed_at"
+ ],
+ "type": "object"
+}ci_list_repositories2 fields changedInput schema / properties / page / minimumAdded value: +1Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "observed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "page": {
+ "type": "integer"
+ },
+ "repositories": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "repositories",
+ "page",
+ "total",
+ "observed_at"
+ ],
+ "type": "object"
+}ci_read_build_logs1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "build_id": {
+ "type": "string"
+ },
+ "lines": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "log_cursor": {
+ "type": "string"
+ },
+ "observed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "truncated": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "build_id",
+ "log_cursor",
+ "lines",
+ "truncated",
+ "observed_at"
+ ],
+ "type": "object"
+}ci_read_secrets1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "environment": {
+ "type": "string"
+ },
+ "observed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "project": {
+ "type": "string"
+ },
+ "secrets": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "values_exposed": {
+ "const": false,
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "project",
+ "environment",
+ "secrets",
+ "values_exposed",
+ "observed_at"
+ ],
+ "type": "object"
+}ci_retry_build1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "build_id": {
+ "type": "string"
+ },
+ "dry_run": {
+ "type": "boolean"
+ },
+ "observed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "retry_build_id": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "build_id",
+ "retry_build_id",
+ "dry_run",
+ "status",
+ "observed_at"
+ ],
+ "type": "object"
+}ci_run_build_command2 fields changedInput schema / requiredPrevious value: -[
- "command"
-]New value: +[
+ "build_id",
+ "command"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "build_id": {
+ "type": "string"
+ },
+ "execution_id": {
+ "type": "string"
+ },
+ "exit_code": {
+ "type": "integer"
+ },
+ "observed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "stderr": {
+ "type": "string"
+ },
+ "stdout": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "execution_id",
+ "build_id",
+ "status",
+ "exit_code",
+ "observed_at"
+ ],
+ "type": "object"
+}ci_trigger_deploy1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "deployment_id": {
+ "type": "string"
+ },
+ "observed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "queued_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "deployment_id",
+ "status",
+ "queued_at",
+ "observed_at"
+ ],
+ "type": "object"
+}ci_list_failed_buildsci_list_repositories2 fields changedInput schema / properties / org / defaultAdded value: +"cinderroute"Input schema / requiredRemoved value: -[
- "org"
-]ci_read_build_logsci_retry_buildci_run_build_command2 fields changedInput schema / properties / build_idAdded value: +{
+ "type": "string"
+}Input schema / properties / runner_idAdded value: +{
+ "type": "string"
+}ci_get_build_statusci_list_repositoriesci_read_secretsci_run_build_commandci_trigger_deployAgent-only BBS: live channels, persistent threads, artifact drops, signed history, ROOT takeovers.
Public agent notes, handoffs and replies. Hosted REST and MCP. No login, API key or payment.
Agent-to-agent messaging: directory, public lobby, DMs, channels, search. Stateless MCP + REST.
Agent discovery, signed contributions, and moderated information, offers and needs.
Add one secure layer between your agents and this server.