Actora B-side tools: hosted chat, sessions, tasks, tenant plan and usage.
Scored across 9 tools
Most tools target a clearly distinct resource+action: task CRUD (create/get/list/cancel), session creation, chat, and tenant account queries. The only borderline pair is chat vs. create_task, which both send content to an agent, but the descriptions (synchronous single-turn reply vs. queued background task with taskId) make the boundary readable.
Task tools follow a clean actora_gateway_verb_noun pattern, but the set splits across two prefixes (actora_gateway_* vs. actora_tenant_*) and actora_gateway_tenant breaks the verb_noun convention as a bare noun that arguably belongs in the tenant_ group. Readable, but the convention is not uniform across all nine names.
Nine tools is well within the sweet spot and each one has a distinct role (session, chat, four task operations, three tenant account operations). No filler or redundant tools; the surface matches the stated scope of chat, tasks, and usage.
Task lifecycle is fully covered (create, get, list, cancel) and tenant profile/plans/usage are present, but session handling is create-only — there is no list/get/delete session or way to retrieve conversation history, which leaves agents at a dead end after creating a session. A get_session or list_sessions tool is the obvious missing piece.
Cancel a task (queued → cancelled; running → aborted; terminal states are idempotent). Requires access_token (registered-user JWT).
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task ID | |
| access_token | No | Gateway JWT — registered-user auth (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses the state machine (queued → cancelled, running → aborted) and declares terminal-state calls idempotent, which is the key safety fact for a mutation. It stops short of saying whether cancellation waits for the abort to complete, what the response confirms, or what error surfaces if the task does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence that front-loads the action and then the per-state outcomes, with a short auth requirement trailing. Every clause conveys something the caller needs; nothing is padding.
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 mutation with no annotations and no output schema, the description covers the essential semantics: what the operation does, how it behaves per state, idempotency, and the auth requirement. The only gap is the absence of any statement about what a successful call returns or confirms.
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%, including the note that access_token is a registered-user JWT, so the schema already documents both parameters. The description's auth note repeats the schema rather than adding format, scope, or acquisition guidance, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb and resource ('Cancel a task') plus the exact outcome per source state (queued → cancelled; running → aborted). It is trivially distinguishable from siblings like actora_gateway_create_task and actora_gateway_get_task without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The state-transition clause effectively tells the agent when calling is safe: terminal states are idempotent, so repeat calls are harmless, while queued/running produce distinct outcomes. There is no explicit exclusion or named alternative, but for a terminal cancel operation none is really needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Single-turn conversation with an agent (SSE stream collected into a reply). Requires access_token (registered-user JWT).
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | Inline mode: caller-supplied system prompt (bypasses agent lookup) | |
| history | No | Optional conversation history [{role, content}] | |
| message | Yes | User message | |
| agent_id | No | Agent ID (omit when using inline prompt) | |
| access_token | No | Gateway JWT — registered-user auth (required) | |
| tenant_key_id | No | BYOK: id of a stored tenant-owned API key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that the SSE stream is collected into a single reply and that a registered-user JWT is required, but says nothing about error behavior, rate limits, or whether the call creates persistent state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core behavior front-loaded and the auth constraint appended. No wasted wording, though the parenthetical could be folded more cleanly.
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 six-parameter tool with no annotations and no output schema, the description is thin: it does not describe the reply shape, error handling, or how inline prompt mode relates to agent_id. Adequate to call it, but not 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 coverage is 100%, so the schema already documents all six parameters including the inline-prompt vs agent_id modes. The description only reinforces the access_token requirement, adding little beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Single-turn conversation with an agent') and clarifies the transport behavior ('SSE stream collected into a reply'). It implicitly distinguishes itself from session/task siblings via 'single-turn', though it never names them explicitly.
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 notes the auth prerequisite (registered-user JWT) but gives no explicit guidance on when to use this versus actora_gateway_create_session or actora_gateway_create_task. Usage is only implied by the 'single-turn' framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a conversation session (dialog container; idempotent). Requires access_token (registered-user JWT).
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Optional session title | |
| agent_id | No | Agent ID | |
| access_token | No | Gateway JWT — registered-user auth (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden, and it does contribute two real behavioral facts: the operation is idempotent and it requires registered-user JWT auth. It stops short of explaining idempotency semantics (does a repeat call return the existing session id?), what the caller receives, or any failure modes, which matters for a creation endpoint that downstream calls depend on.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the core action front-loaded and the auth requirement second; no filler, no restatement of the tool name beyond what is needed. Everything present 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 three-parameter creation tool with full schema coverage and no output schema, the definition covers purpose, idempotency, and auth. The main omission is what the call yields (presumably a session identifier consumed by actora_gateway_chat), which the absence of an output schema makes more important to state, but the remainder is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented inline, giving a baseline of 3. The description only restates that access_token is a required registered-user JWT — duplicating the schema — and adds nothing about how title or agent_id affect the created session.
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 and resource ("Create a conversation session") and clarifies the domain term with "dialog container", so an agent knows exactly what object is produced. It does not explicitly contrast itself with the task-oriented siblings (create_task, chat, get_task), but the resource distinction is clear enough to separate it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the agent can infer a session is the prerequisite container for chat/agent interactions, and the description states the auth prerequisite (registered-user JWT). There is no explicit statement of when to call this versus actora_gateway_chat or actora_gateway_create_task, and no exclusions or prerequisite sequencing described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a background task in a session (returns immediately with taskId; queued→running→done). May return 403 PARALLEL_TASKS_DISABLED. Requires access_token (registered-user JWT).
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | Inline mode: caller-supplied system prompt | |
| message | Yes | Task instruction | |
| agent_id | No | Agent ID (omit when using inline prompt) | |
| session_id | Yes | Session ID (from actora_gateway_create_session) | |
| access_token | No | Gateway JWT — registered-user auth (required) | |
| tenant_key_id | No | BYOK: id of a stored tenant-owned API key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations the description carries the full burden, and it discloses real behavior: asynchronous execution with an immediate taskId return, the queued→running→done state progression, a specific failure mode (403 PARALLEL_TASKS_DISABLED), and the registered-user JWT auth requirement. It stops short of describing what happens to a task on failure or how results are retrieved afterward.
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 dense sentences front-load the core action and async semantics, then attach the error and auth constraints parenthetically. Every clause carries operational information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter mutation tool with no annotations and no output schema, the description covers the essential async contract, auth requirement, and a known error code. The notable gap is not telling the agent how to follow up on the returned taskId (actora_gateway_get_task) or listing any other error conditions.
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 every parameter is already documented in the input schema, including the inline-prompt vs agent_id tradeoff and the BYOK tenant_key_id. The description adds no parameter-level detail beyond restating that access_token is a required registered-user JWT, 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?
States a specific verb and resource ("Create a background task in a session") and immediately contrasts it with synchronous behavior via "returns immediately with taskId". This implicitly separates it from actora_gateway_chat, but no sibling is named explicitly, so differentiation depends on inference.
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 word "background" plus the immediate-return note implies this is for long-running work that should not block, which is usable guidance. However, there is no explicit when-not clause and no pointer to alternatives like actora_gateway_chat for synchronous turns or actora_gateway_get_task for polling results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get task detail by id (status, result, error). Requires access_token (registered-user JWT).
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task ID | |
| access_token | No | Gateway JWT — registered-user auth (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does surface the key operational constraint: a registered-user JWT access_token is required. It does not say whether an unknown or unauthorized task_id produces an error versus an empty result, nor does it mention any rate limits or side effects (though the operation reads as non-mutating).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler; the primary action appears first and the auth requirement second. Nothing is redundant.
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 with no output schema and fully described parameters, the description covers purpose, return fields, and the authentication prerequisite. Only error behavior for invalid or missing task ids remains unspecified, which is minor.
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 documents both task_id and access_token including the registered-user JWT requirement. The description's parenthetical restates that constraint rather than adding format or acquisition details, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Get task detail by id') and names the returned fields (status, result, error), so an agent knows exactly what it retrieves. It is distinguishable from the sibling list_tasks, but it does not explicitly contrast itself with list_tasks or create_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: by-id retrieval suggests you need an existing task_id, which list_tasks would supply. No explicit when-to-use or when-not-to-use guidance, and no named alternative for cases like looking up many tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tasks of a session. Requires access_token (registered-user JWT).
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session ID | |
| access_token | No | Gateway JWT — registered-user auth (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it only restates the authentication requirement already present in the schema. It says nothing about pagination, result ordering, behavior for an invalid or expired session, or whether all tasks are returned or a truncated page.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core action front-loaded and the auth prerequisite second. No filler or redundant phrasing.
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 with no output schema, the description covers purpose and auth adequately. However, without annotations or a return schema, it should at least sketch the return shape or pagination behavior to be 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 both session_id and access_token are already documented in the input schema. The description adds no syntax, format, or constraint detail beyond that, making the baseline 3 correct.
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?
Uses a specific verb and resource ("List all tasks") scoped to a session, which clearly separates it from the single-item sibling actora_gateway_get_task. It stops short of explicitly naming that sibling, so differentiation is inferable rather than stated.
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 scope phrase "of a session" implies when this tool applies (enumerating tasks for a known session), but there is no explicit when/when-not guidance and no reference to alternatives such as get_task or cancel_task. Usage must be inferred from the tool name and scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get tenant profile, plan, quota.
| Name | Required | Description | Default |
|---|---|---|---|
| accessToken | Yes | Gateway JWT token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden and does not meet it. 'Get' implies a read, but there is nothing about the required JWT/authorization context, whether results are scoped to the token's tenant, rate limits, or what the response shape looks like.
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?
One short sentence with zero filler, and the key noun (tenant) is front-loaded. It is efficient, though the terseness pushes the missing information into the other dimensions rather than making the sentence itself wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with full schema coverage and no output schema, the description minimally covers what is returned. It leaves unresolved how this differs from actora_tenant_plans and actora_tenant_usage and says nothing about authorization behavior, which is the main gap for an agent that must choose 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?
There is a single parameter with 100% schema description coverage ('Gateway JWT token'), so the schema already explains it. The description adds no meaning about the token's scope or how tenant resolution works, which is the baseline expectation when the schema is complete.
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 ('Get') and resource ('tenant') plus the data returned (profile, plan, quota), so an agent knows it is a read of tenant metadata. It does not distinguish itself from the overlapping siblings actora_tenant_plans and actora_tenant_usage, which appear to cover part of the same ground.
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 when-to-use guidance and no mention of alternatives. Given two siblings named for tenant plans and tenant usage, an agent has to guess whether this tool supersedes them or complements them; the description offers no routing signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List platform plans for B-side tenants (Free / Pro / Enterprise: quota, rate limit, concurrency, BYOK). Requires access_token (registered-user JWT).
| Name | Required | Description | Default |
|---|---|---|---|
| access_token | Yes | Gateway JWT (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. "List" implies a non-mutating read and the token constraint discloses an auth prerequisite, but it says nothing about pagination, whether the catalog is a fixed enumeration or tenant-specific, or error behavior for unregistered tokens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler, and the purpose is front-loaded ahead of the auth requirement. Slightly dense parenthetical enumeration but every clause carries 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 one-parameter read tool with no output schema, the description covers what the tool returns and the auth requirement, which is close to sufficient. The remaining gap, the exact shape of each plan record, is minor and partially addressed by the enumerated fields.
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 labels access_token as a required Gateway JWT. The description adds only that it must be a registered-user token, a marginal clarification; baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("List") and a well-scoped resource ("platform plans for B-side tenants"), and enumerates the plan attributes returned (quota, rate limit, concurrency, BYOK). The scope distinguishes it from actora_tenant_usage, but the description never names that sibling, so differentiation is left implicit.
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?
Gives a prerequisite ("Requires access_token (registered-user JWT)") which implies the caller must be a registered user, but offers no explicit when-to-use guidance, no when-not-to-use, and no pointer to actora_tenant_usage for consumption data rather than plan metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Token/tool-call usage summary and daily timeline for the current tenant. Requires access_token (registered-user JWT).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days (1..365, default 30) | |
| access_token | Yes | Gateway JWT (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the auth requirement ('registered-user JWT') and what the payload contains (summary plus daily timeline), which is real added context. It omits read-only guarantees, rate limiting, and any pagination or granularity caveats.
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, and the payload description is front-loaded ahead of the auth prerequisite. Every clause carries information an agent needs.
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 read tool this is close to adequate, but with no output schema the description should say more about the shape of the 'summary' and 'daily timeline' (granularity, per-day fields). The auth prerequisite is covered, so the remaining gap is return-value detail.
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 'days' fully documented (1..365, default 30), so the baseline is 3. The description adds a nuance by calling the token a 'registered-user JWT', though that slightly diverges from the schema's 'Gateway JWT' wording without explaining the difference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: 'Token/tool-call usage summary and daily timeline for the current tenant'. The verb is implicit (retrieve/report) but the resource is unambiguous and distinguishable from siblings like actora_tenant_plans. It does not explicitly name a sibling it is not, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'for the current tenant' establishes scope, and the resource name suggests you call it to inspect consumption. There is no explicit when-to-use, no when-not-to-use, and no alternative named (e.g. actora_tenant_plans for plan/quota details).
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.
actora_gateway_cancel_taskactora_gateway_chatactora_gateway_create_sessionactora_gateway_create_taskactora_gateway_get_taskactora_gateway_list_tasksactora_gateway_tenantactora_tenant_plansactora_tenant_usageTime tracking, tasks and team chat for humans and AI agents.
Aztra workspace: projects, issues, sprints, goals, wiki and time tracking.
Public and private rooms for agents, with messages, files, search, and resumable events.
Task and sprint coordination for humans and AI agents, with scoped API keys and full audit trail.
Add one secure layer between your agents and this server.