Run and manage H Company's Computer-Use Agents from any MCP client.
Scored across 9 tools
Each tool targets a distinct action and resource: session lifecycle (run, wait, cancel, send, share), agent discovery (list), and file operations (list, read, write). No two tools overlap in purpose.
All tools follow a consistent verb_noun snake_case pattern (cancel_session, list_agents, read_file, etc.), making the API predictable and easy to navigate.
With 9 tools, the surface is well-scoped for a computer-use agent API, covering session management, agent execution, file operations, and sharing without bloat.
Core workflows are covered (start, monitor, interact, cancel, share, file access), but missing delete_file and list_sessions are minor gaps that agents can work around.
Cancel a session; a no-op if it does not exist or already finished.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states the operation and idempotency, but does not mention permissions, side effects (e.g., resource release), or what happens to a running session beyond cancellation. Adequate but leaves some gaps.
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, 13 words, front-loaded with the verb and resource. Every word earns its place, 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?
The tool is simple (1 param, no nested objects, has output schema). Description covers purpose and idempotency. Could mention output structure or side effects, but given low complexity, it is mostly 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?
Only one parameter (session_id) with no description in the schema. The description does not elaborate on its format, constraints, or meaning beyond what the name implies. Since schema coverage is 0%, the description should compensate, but it fails to add value.
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?
Name and description clearly state the action (cancel) and resource (session). Idempotency detail distinguishes it from siblings, all of which are different 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?
The description explicitly says 'Cancel a session' and clarifies that it's a no-op if the session does not exist or is already finished, giving clear context on when to use it. No explicit alternatives are needed as no sibling tool performs cancellation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List agents the caller can run: their org's agents plus the public h/ ones.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| size | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. However, it does not disclose pagination behavior, rate limits, required permissions, or any side effects. It only states 'List agents' without further 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 a single concise sentence that communicates the core purpose. It is front-loaded and avoids unnecessary words. However, it could include parameter info 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 no annotations, low parameter coverage, and sibling tools like 'run_agent', the description is incomplete. It does not explain what the output contains, pagination, or how to interpret results. The output schema exists but does not fully compensate for missing behavioral 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 two parameters (page, size) with defaults, but the description does not explain their meaning or usage. Schema description coverage is 0%, and the description fails to compensate, providing no parameter semantics.
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 agents the caller can run, specifying the scope as their org's agents and public 'h/' ones. It uses a specific verb ('list') and resource ('agents'), distinguishing it from sibling tools like 'run_agent' or 'cancel_session'.
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 available agents before running them, but does not explicitly state when to use this tool versus alternatives like 'run_agent'. No guidance on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files on a browser session's machine (e.g. downloads), newest first.
session_id is the browser session id issued by env-manager when the session was
created, not the id run_agent returns.
When a listing is truncated, page on the last entry's modified_at (ISO-8601) and name, passed as modified_before and name_after. Send both: modification times are not unique, and a timestamp alone skips the rest of a tied group.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ~/Downloads | |
| name_after | No | ||
| session_id | Yes | ||
| max_entries | No | ||
| modified_before | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It reveals sorting order (newest first), explains the correct session_id source (env-manager vs run_agent), and details pagination semantics (using modified_before and name_after together, with ISO-8601 timestamps and the reason for sending both). This goes well beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, uses four sentences with no filler. The core purpose is front-loaded, followed by essential clarifications. Every sentence contributes valuable behavioral information, making it highly 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?
Given the tool's moderate complexity, the description covers the key behavioral aspects: purpose, session_id source, pagination rules, and ordering. The output schema exists to document return values, so nothing critical is missing for an agent to call 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?
Schema description coverage is 0%, so the description must add meaning for all parameters. It clarifies session_id (which ID to use), and explains modified_before/name_after in the context of pagination. It does not elaborate on path or max_entries, but their defaults are in the schema. Overall it meaningfully supplements the schema for three of five 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 verb (List) and resource (files on a browser session's machine), with an example (downloads). It distinguishes from siblings like read_file and write_file by specifying listing behavior, so an agent can select it correctly.
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 that this tool lists files, and its naming distinguishes it from read/write operations. It does not explicitly name alternatives or exclusions, but the purpose is unambiguous and the sibling list makes routing straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a file from a browser session's machine; returns base64 content and metadata.
session_id is the browser session id issued by env-manager when the session was
created, not the id run_agent returns.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 the return format (base64 content and metadata) and clarifies the critical session_id source, adding value beyond the schema. However, it does not mention any potential side effects or error conditions, though 'read' implies 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, front-loaded with the core action and return info, followed by a critical note about session_id. No filler or redundancy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, so the description needn't explain them, but it already does. Main gaps are the lack of path format details and explicit usage guidance. For a simple two-parameter tool, it's reasonably complete but has room to specify path semantics and when to use this instead of list_files.
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 explains session_id in detail (issued by env-manager, not run_agent), which is valuable, but it does not describe the path parameter (e.g., absolute vs relative). Thus it partially compensates for the schema gap but leaves one parameter undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read'), a resource ('a file from a browser session's machine'), and what it returns ('base64 content and metadata'). This clearly distinguishes it from sibling tools like list_files (which lists) and write_file (which writes).
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 via its purpose but provides no explicit guidance on when to use this tool over alternatives like list_files or when not to use it. There is no mention of exclusions or prerequisites, leaving the decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an agent on a task; return the answer or a session handle to wait on. agent from list_agents.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| agent | Yes | ||
| max_steps | No | ||
| max_time_s | No | ||
| idempotency_key | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states the basic action and outcome, without mentioning potential side effects, resource usage, authentication needs, or error conditions.
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, immediately stating the purpose and key outcome. Every word adds value, and it is front-loaded for quick comprehension.
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 having an output schema, the description fails to explain when to expect an answer versus a session handle, how parameters like max_steps or max_time_s affect behavior, or how this tool interacts with others like wait_for_session.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning only for the 'agent' parameter by referring to list_agents. The other four parameters (task, max_steps, max_time_s, idempotency_key) are not described, and schema coverage is 0%, leaving their purpose unclear.
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 the verb 'start' with the resource 'agent on a task', which clearly indicates the action. It also mentions returning an answer or session handle, and references 'agent from list_agents', which distinguishes it from sibling tools like list_agents and wait_for_session.
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 implicitly suggests use after list_agents by referencing it, but does not explicitly state when to use this tool versus alternatives like send_message or wait_for_session. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a follow-up message to a running session.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 only states the action 'send' but does not explain blocking behavior, return values, side effects, or any permissions needed. 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 that conveys the core purpose efficiently. It is front-loaded and contains no unnecessary words, though it could be expanded with behavioral details 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?
Despite having an output schema, the description lacks essential context like whether the call is blocking, what happens if the session is not running, or how to interpret the response. For a tool with no annotations, this is incomplete.
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 adds almost no meaning beyond parameter names. 'message' and 'session_id' are self-explanatory from their names, but no format, constraints, or usage hints are 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 verb 'send', the resource 'message', and the context 'follow-up to a running session'. It distinguishes this tool from siblings like cancel_session or run_agent because no other sibling sends messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that the tool is for sending a follow-up message to a 'running session', implying prerequisite of having an active session. However, it does not explicitly mention when not to use it or provide alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a session: with wait long-poll for the answer, else return the current snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | ||
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 of behavioral disclosure. It mentions long-polling and snapshot return but omits critical details like blocking behavior, timeout, error conditions, or safety. The read-only nature is implied but not explicit.
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 fluff, using backticks for code formatting. It's appropriately concise, though it could benefit from a bit more structure to separate modes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return shape is covered. However, the description lacks context on prerequisites, error handling, and when to use each mode. The minimal description is adequate for a simple tool but leaves room for improvement.
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 explains the 'wait' parameter (long-poll vs snapshot) but fails to describe the 'session_id' parameter or its format. Only one of two parameters is addressed, leaving a significant 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 uses a specific verb 'Poll a session' and distinguishes two modes (long-poll vs snapshot), clearly identifying the resource and action. However, it doesn't differentiate from siblings like cancel_session or send_message, though those are distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to get session answer or snapshot) but lacks explicit guidance on when not to use it or alternatives. No exclusions are mentioned, but the behavioral difference is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write base64-encoded content to a file on a browser session's machine.
session_id is the browser session id issued by env-manager when the session was
created, not the id run_agent returns.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| session_id | Yes | ||
| content_base64 | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the write action; it does not mention whether files are overwritten, if directories are created, or how failures are reported. No edge cases or side effects are 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 sentences with no waste. The first sentence states the core action, and the second clarifies a common source of confusion. Information 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?
Covers the essential action and the session_id clarification, but lacks details on overwrite behavior, error handling, or file path semantics. Since an output schema exists, return value details are handled elsewhere, which partially compensates for the 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 has zero descriptions for parameters, so the description must compensate. It clarifies that session_id is the env-manager session id, not the one from run_agent, which is valuable. Path and content_base64 are self-explanatory given the tool's purpose, but they are not explicitly defined.
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 exactly what the tool does: writes base64-encoded content to a file on a browser session's machine. This clearly distinguishes it from siblings like read_file and list_files. The additional clarification about session_id 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?
The description implies the tool is for writing files but does not explicitly mention when to use it over alternatives like read_file or list_files. The session_id note addresses parameter semantics, not tool selection, so usage context is only implied.
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.
list_filesread_filewrite_filecancel_sessionlist_agentsrun_agentsend_messageshare_sessionwait_for_sessionPublish and manage existing HTML presentations from an MCP-capable Agent.
Agent-first web hosting: deploy sites, apps, databases and domains over MCP.
Remote MCP server to read and manage your Atako AI agents, messages, files, and integrations.
MCP-first control plane for ProAgentStore agents and private instances.
Add one secure layer between your agents and this server.
