Skip to main content
Glama
Sign In
ArchiveBox API

ArchiveBox API

by Knuckles-Team
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Get binary

archivebox_get_binary
Read-onlyIdempotent

Retrieve a single stored binary from ArchiveBox by its binary ID to inspect details or manage archived binary content.

Instructions

GET /api/v1/machine/binary/{binary_id}

Read one binary.

Args: binary_id: The binary id.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "binary_id": "<binary_id>"
    },
    "name": "archivebox_get_binary"
  }
}

Input Schema

NameRequiredDescriptionDefault
binary_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.6.0

TDQS

C2.2/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds no behavior beyond that — no 404/not-found semantics, no auth requirement, no note on what a binary record contains — so it contributes essentially nothing beyond structured data.

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

Conciseness3/5

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

It is short and the resource statement is front-loaded, but the raw endpoint line and the redundant Args block are waste; the definition reads like dumped OpenAPI text rather than tuned agent guidance.

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

Completeness2/5

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

For a single-parameter read tool with no output schema, the description must carry the burden of explaining the return value, auth, and identity format. It does none of these, leaving an agent unable to know what it gets back or how to form a valid id.

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

Parameters1/5

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

Schema description coverage is 0% and the only parameter documentation is 'binary_id: The binary id,' a pure tautology. It fails to clarify whether the id is an integer, UUID, or slug, which is critical when the schema itself says only 'string'.

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

Purpose3/5

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

The description says 'Read one binary,' which is a specific verb and resource, but it never defines what a 'binary' is in ArchiveBox terms and does not distinguish this from the sibling archivebox_get_binaries list tool. The raw HTTP route restatement doesn't help an agent choose between the two.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no mention of required authentication (despite an archivebox_check_api_token sibling existing), and no stated alternative such as archivebox_get_binaries for listing. The agent must infer everything from the tool name.

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

Deploy Server

Other Tools