OneSimpleAPI

POST /api/pdf/signing/{id}/recipients/{recipientId}/resend

api_post_pdf_signing_id_recipients_recipientid_resend

Destructive

Existing api/pdf/signing/{id}/recipients/{recipientId}/resend 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

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": {
      "path": "<path>"
    },
    "name": "api_post_pdf_signing_id_recipients_recipientid_resend"
  }
}

Input Schema

Name	Required	Description
`body`	No	API request body. Nested objects, arrays, HTML, base64 data and all API options retain their original meaning.
`path`	Yes
`files`	No	Multipart 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.
`query`	No	URL query parameters. Sensitive API options must be in body as documented by the API.
`method`	No
`headers`	No	API request headers such as Idempotency-Key, Range and If-None-Match. Authentication and transport headers are managed by the connection.
`content_type`	No	Defaults to application/json, or multipart/form-data when files are supplied.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

C2.1/5.0

Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false, so the agent knows this mutates state — but the description adds nothing about the actual effect (an outbound email is dispatched, prior links may be invalidated, repeated calls send duplicate mail). It does disclose useful transport behavior (HTTP status/headers/body are preserved, redirects are not followed), which is why this isn't a 1.

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?

The text is short and free of padding, but it is not front-loaded: the opening sentence is a tautology of the tool name, and the genuinely useful content (parameter placement, output/redirect semantics) trails behind it. No sentence is wasted, yet the most informative ones come last.

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 destructive, non-idempotent mutation with 7 parameters and nested body/query objects, the definition omits the essential facts: what gets re-sent, to whom, and under what preconditions (e.g. request must still be pending). There is no output schema, and while the description covers response passthrough, the operation's semantics remain undocumented.

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

Parameters2/5

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

The description contributes only "supply API parameters in query or body"; it never explains that `path.id` is the signing request and `path.recipientId` the target recipient. Schema coverage is 71% but the parameter descriptions are vacuous boilerplate ("Existing API option; validated by the shared API implementation"), so the schema does not compensate either, leaving the meaning of the required path parameters unexplained.

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

Purpose2/5

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

The description only restates the endpoint path ("Existing api/pdf/signing/{id}/recipients/{recipientId}/resend API operation") without ever saying what the operation does — i.e. that it re-sends the signing invitation to a specific recipient. The verb is buried in the URL slug, so an agent must infer purpose from the name alone, and nothing distinguishes it from the sibling api_post_pdf_signing_id_send.

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?

No when-to-use guidance is given: nothing states that this should be used when a recipient missed or lost an invitation, nor when to prefer the broader `send` endpoint. The only routing-adjacent statement is that parameters may go in query or body, which is transport guidance rather than usage guidance.

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

All OneSimpleAPI tools Inspect

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

Need Help?