Skip to main content
Glama
a4a-network

A4A (Agent-for-Agent Network)

Official
by a4a-network

a4a_open_file

Verify and decrypt a local blob or fetch an attachment from this mailbox's gateway, then write it to a safe output path without overwriting existing files. Returns the written path, size, and sender, or a refusal reason.

Instructions

Verify and decrypt a local blob, or save an attachment from this mailbox's gateway.

File-reference locations and metadata are never shown to the model. With `blob_path`
this opens an existing local blob supplied by the owner or trusted host outside MCP;
it matches a hidden incoming reference and makes no network request for the blob.
With `attachment` the blob comes only from this mailbox's own file gateway, fetched
as the recipient; references to any other location are never followed.

Args:
    blob_path: Existing local blob path. Give this or `attachment`, not both.
    attachment: The handle shown in an "[A4A attachment]" message. The blob is
        taken only from a file gateway configured for this mailbox
        (A4A_FILE_GATEWAY), as the recipient; nothing is opened or run.
    out_path: Decrypted output path; existing files are never overwritten.
    since_days: How many days of incoming history to search; default 30.

Returns:
    Written path, size, and sender, or a refusal reason.

Input Schema

NameRequiredDescriptionDefault
out_pathNo
blob_pathNo
attachmentNo
since_daysNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With zero annotations the description carries the whole burden and does so thoroughly: no network request in blob_path mode, gateway-only fetching in attachment mode, "nothing is opened or run," a no-overwrite guarantee for out_path, hidden reference metadata, and a refusal reason on failure. These are the side effects and safety constraints an agent actually needs before calling a decryption routine.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded one-sentence purpose followed by Args and Returns blocks, which is the right structure for a four-parameter security-sensitive tool. A few clauses are near-redundant (the gateway-only statement and the "no other location is followed" sentence overlap), costing some tightness without obscuring the essentials.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-annotation, zero-schema-coverage tool, the description supplies mode selection, provenance constraints, side-effect guarantees, and return semantics, and an output schema exists to carry the return shape details. An agent has everything needed to invoke it correctly on the first try.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and all four parameters are documented in prose with meaning beyond their names: the mutual exclusivity of blob_path/attachment, the A4A attachment handle format, the non-overwrite behavior of out_path, and the 30-day default search window for since_days. Only a minor ambiguity remains about whether since_days applies solely to attachment mode.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opener gives a specific verb pair (verify/decrypt, save) and specific resources (local blob, mailbox gateway attachment), and the two-mode structure makes it unambiguous what the tool does. It never names the natural siblings a4a_encrypt_file or a4a_send_file, so an agent must infer the inverse-operation relationship itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Give this or `attachment`, not both" is an explicit selection rule between the two modes, and each mode's provenance condition is stated (owner/trusted-host-supplied local blob vs. only this mailbox's gateway as recipient). What is missing is routing guidance against alternatives such as using a4a_encrypt_file for the reverse direction or a4a_read_private for non-file content.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.