Skip to main content
Glama

Request Datasheet Upload

request_datasheet_upload

Free. The upload fee is charged by confirm_datasheet_upload, after the file is checked. Gives a signed URL to upload a datasheet PDF we don't have: use it when datasheet_status is 'no_source' (once the search has finished: not while it is 'resolving') or 'unsupported'. Three steps:

  1. Call this with the MPN, the file's SHA-256 and its byte size; you get upload_url, upload_method ('PUT'), upload_headers and an upload_token.

  2. Upload the bytes: curl -X PUT -H 'Content-Type: application/pdf' --data-binary @file.pdf "$UPLOAD_URL" (plus any upload_headers).

  3. Call confirm_datasheet_upload with the upload_token. Checked at confirm (nothing charged if a check fails): a parseable PDF, the SHA-256 and size you declared, and the MPN or its stem on the first page (scanned image-only PDFs fail this). Max 50 MB; the part's datasheet, not a dev-kit manual, schematic or app note. Uploaded datasheets are private to your organisation. Tokens expire after 15 minutes; request a new one if needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
size_bytesYesSize of the PDF in bytes (1,024 to 50,000,000).
part_numberYesMPN the PDF belongs to. Not a value or description.
manufacturerNoOptional manufacturer name (e.g. 'Texas Instruments') when the MPN alone is ambiguous.
expected_sha256YesLowercase hex SHA-256 of the PDF bytes (64 chars), e.g. from `shasum -a 256 file.pdf`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / expected_sha256 / description
      Previous value: -"Lowercase hex SHA-256 of the PDF bytes (64 chars). Used both as the storage key (content-addressed) and to detect tampering. Compute with `shasum -a 256 file.pdf`."New value: +"Lowercase hex SHA-256 of the PDF bytes (64 chars), e.g. from `shasum -a 256 file.pdf`."
    • changedInput schema / properties / manufacturer / description
      Previous value: -"Optional. Manufacturer name (e.g. 'Texas Instruments') if the MPN alone doesn't disambiguate."New value: +"Optional manufacturer name (e.g. 'Texas Instruments') when the MPN alone is ambiguous."
    • changedInput schema / properties / part_number / description
      Previous value: -"Manufacturer part number the PDF belongs to. Must be a real MPN, not a value or description."New value: +"MPN the PDF belongs to. Not a value or description."
    • changedInput schema / properties / size_bytes / description
      Previous value: -"Size of the PDF in bytes. Must be ≤ 50_000_000 (50MB) and > 1024."New value: +"Size of the PDF in bytes (1,024 to 50,000,000)."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare it is a write with no destruction; the description adds substantial non-obvious behavior: it is free but the fee is charged at confirm, validation rules (parseable PDF, declared hash/size, MPN on first page, image-only PDFs fail), 50 MB limit, org-private results, and 15-minute token expiry.

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 with the key cost fact ('Free.') and organized as a numbered three-step flow, so structure is strong. It is long and slightly repetitive (fee and checks restated), which keeps it from a 5, but almost every sentence carries actionable information.

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?

There is no output schema, yet the description enumerates the returned fields (upload_url, upload_method, upload_headers, upload_token) and the full two-step follow-through, so an agent has everything needed to complete the workflow.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning by explaining what the SHA-256 and byte size are checked against at confirm time and by clarifying the MPN-or-stem matching rule on page one. It does not add syntactic detail beyond the schema's examples.

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

Purpose5/5

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

States a specific verb+resource: obtaining a signed URL to upload a datasheet PDF. It clearly distinguishes itself from siblings by naming confirm_datasheet_upload as the follow-up and by scoping to cases where the datasheet is absent.

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

Usage Guidelines5/5

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

Gives explicit trigger conditions (datasheet_status 'no_source' after search completes, or 'unsupported'), an explicit exclusion (not while 'resolving'), and routes the agent to confirm_datasheet_upload as the required next step. Nothing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.