Skip to main content
Glama
Sign In

OneSimpleAPI

by com.onesimpleapi
OverviewDiscussionsAdmin

POST /api/files/capture-link

api_post_files_capture_link
Destructive

Existing api/files/capture-link API operation. Uses the OneSimpleAPI API (https://onesimpleapi.com/docs), with the same permissions, credits and storage. Supply API parameters in query or body. method defaults to POST. Outputs preserve HTTP status, headers and JSON/text/base64 body; redirects are returned without following them.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "api_post_files_capture_link"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoAPI request body. Nested objects, arrays, HTML, base64 data and all API options retain their original meaning.
pathNo
filesNoMultipart uploads keyed by API field name (for example pdf). Supply file_name, base64 bytes and optional mime_type. Uploads use the existing API file validators.
queryNoURL query parameters. Sensitive API options must be in body as documented by the API.
methodNo
headersNoAPI request headers such as Idempotency-Key, Range and If-None-Match. Authentication and transport headers are managed by the connection.
content_typeNoDefaults to application/json, or multipart/form-data when files are supplied.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior3/5

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

Beyond the annotations it usefully discloses that calls consume credits/storage under the same permission model, that HTTP status, headers, and JSON/text/base64 bodies are preserved verbatim, and that redirects are returned unfollowed — real behavioral value. However, annotations mark this destructiveHint=true and non-idempotent, and the description never explains what is mutated or why a repeat call could differ, leaving the highest-risk trait undisclosed.

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?

Five tight sentences with the routing information (provider, credits, POST default) up front and output fidelity after. Some boilerplate in the opening two sentences ('Existing ... API operation', provider URL) is filler, keeping it short of a 5.

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

Completeness3/5

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

The description correctly covers the output contract (status, headers, body, redirects) and thus compensates for the absent output schema, and it warns about credit consumption. What it omits is the actual semantic of the operation and the destructive/non-idempotent consequence, which for a 7-parameter nested-body write tool is a material gap.

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

Parameters3/5

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

Schema description coverage is 71%, so the baseline is 3. The description confirms query-or-body placement and the POST default but adds no meaning about the most important parameter, `url`, which the schema only labels as an 'existing API parameter processed by UserFileController@captureLink'.

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 definition names the underlying endpoint (api/files/capture-link) and the upstream provider, but never says what "capture-link" actually does to its input URL (archive, screenshot, download?). An agent learns the resource path but not the effect, so it can only distinguish this from siblings by their paths, not by behavior.

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 and no routing to alternatives among the many sibling POST endpoints. The only operational guidance is 'supply parameters in query or body' and the POST default, which is invocation mechanics rather than usage context.

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

All OneSimpleAPI toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources