Skip to main content
Glama

Connect the person's ReflowPDF account

connect_account
Read-onlyIdempotent

Signs the person in to their ReflowPDF account (a free one is enough), when they want PDFs without the ReflowPDF mark, their plan's pages, or the documents you make kept in their account. Their client shows a Connect button; once they have signed in, every call of yours is their account's. Without it everything works too, as a guest: every page, with a small mark.

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": "connect_account"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
notesYes
connectedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, non-open-world behavior. The description adds meaningful context beyond that: a free account is enough, the client shows a Connect button, signing in changes the account context for all subsequent calls, and guest mode remains available.

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

Conciseness5/5

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

It is front-loaded with the action, then gives the relevant conditions and the guest fallback in three tight sentences. Every sentence contributes useful information without repetition.

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 zero-parameter account-connection tool with annotations and an output schema, the description covers purpose, account benefits, UI behavior, global effect on later calls, and the guest alternative. Return values are appropriately left to the output schema.

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?

There are no parameters, so there is no parameter semantics to explain. The description correctly does not invent parameter details, and the baseline for zero-parameter tools is 4.

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?

The description opens with a specific verb and resource: 'Signs the person in to their ReflowPDF account.' It makes the account-scope purpose explicit and distinguishes this from the sibling PDF/document tools.

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?

It states when to use the tool: when the person wants PDFs without the ReflowPDF mark, their plan's pages, or documents kept in their account. It also explicitly describes the alternative: without connecting, everything still works as a guest with a small mark.

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.