PaperLumo PDF MCP

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

Annotations already mark the operation as destructive, but the description adds meaningful detail beyond that: the deletion is immediate and irreversible ('cannot be undone') and has no credit cost. These are practical consequences not present in the structured annotations. No contradiction with annotations.

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

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

Two short sentences, front-loaded with the core action and resource, followed by the two most important behavioral caveats. Every phrase adds value, and there is no redundancy or irrelevant detail.

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

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

For a one-parameter destructive action, the description covers the purpose, the irreversibility, and the cost, while the schema handles the required parameter. An agent has enough to decide and invoke the tool correctly. The only minor gap is that the origin of fileId is not stated, but that is not critical given the simple interface.

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

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

The schema has one required fileId parameter with 0% description coverage, and the tool description does not explicitly explain what fileId refers to or how to obtain it. The phrase 'delete an owned temporary document' suggests the fileId identifies that document, but the link is left to inference, so the description barely compensates for the missing schema documentation.

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

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

The description names a specific verb ('delete') and a specific resource ('owned temporary document'), making the operation unambiguous. It also stands apart from all siblings, which concern downloading, uploading, converting, or transforming documents rather than removing them.

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

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

The description clearly frames when to use the tool: to immediately remove an owned temporary document. It does not explicitly name alternatives or exclusions, but since it is the only deletion tool among the siblings, the usage context is evident and the caveat about irreversibility reinforces appropriate caution.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral context: the document is owned and temporary, the result is base64, the size is capped at 5 MB, and using this tool may put large content into model context. These details go beyond the structured annotations without contradicting them.

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

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

The description is compact: two sentences, front-loaded with the core action and format, followed by a relevant routing instruction. Every sentence contributes actionable information with no filler.

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

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

For a single-parameter read operation, the description provides the key operational details: base64 output, 5 MB limit, ownership/temporary nature, and a safer alternative for binary downloads. It does not cover error behavior or expiration, but the annotations and simple input schema keep the remaining gap minor.

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

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

Schema coverage is 0%, so the description must compensate for parameter documentation, but it does not explain the fileId parameter at all. The name fileId and pattern hint at an identifier, but the description never states that this parameter selects the document to download or connects it to the 'owned temporary document' concept.

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

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

The description states a specific verb ('Get'), a resource ('owned temporary document'), and a concrete output format ('base64' with a maximum size). This clearly differentiates it from the sibling pdf/upload/delete tools and makes the tool's function immediately identifiable.

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

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

The description explicitly names an alternative endpoint and gives the condition for preferring it: 'Prefer authenticated GET /api/mcp/files?id=FILE_ID for binary downloads to avoid large model context.' This provides clear context for when not to use this tool, though it does not explicitly spell out the positive condition for choosing this tool beyond its base64 purpose.

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

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

Annotations declare readOnlyHint=true, and the description is consistent, describing a read-only lookup. The description adds behavioral traits beyond annotations: it states there is no credit cost and that files expire, requiring a new upload. These are important operational details not present in the annotations.

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

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

The description is two concise sentences, with the purpose front-loaded in the first sentence and additional operational details in the second. Every sentence adds value, and there is no redundancy.

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

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

The tool is simple with one parameter and read-only behavior, and the description covers purpose, cost, and expiry. However, it does not describe the output structure or any error conditions, which could be important for an agent to know. Given the simplicity, it is fairly complete but not fully comprehensive.

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

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

The schema has one required parameter, requestId, with 0% description coverage. The description mentions requestId in the context of expiry, implying it is the identifier for the operation, but it does not explicitly define its role or format beyond the schema pattern. Since the description carries the burden for parameter explanation, it only partially compensates for the lack of schema descriptions.

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

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

The description uses a specific verb 'look up' and a specific resource 'owned operation and its temporary output', making the tool's purpose clear. It distinguishes itself from sibling tools which are all document processing operations, as this is about retrieving job results.

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

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

The description provides key usage context: it notes there is no credit cost and that expired files require a new upload and requestId. While it doesn't explicitly name alternative tools, it implies that if the file has expired, one should re-upload and get a new requestId, which guides usage. However, it doesn't explicitly state when not to use this tool, but the context is sufficient.

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

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

Annotations already declare readOnlyHint=true, so the description's 'Read' and 'No credit cost' add useful behavioral context beyond the annotation. It doesn't describe return format or pagination, but for a zero-parameter read tool with readOnlyHint, the description covers the key behavioral trait.

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

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

Two short sentences with no wasted words. The core purpose is front-loaded, and the cost note is a valuable addition.

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

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

For a zero-parameter read-only tool with readOnlyHint annotation, the description is nearly complete. It could mention what the response contains (e.g., numeric values) but the description's mention of credits used/reserved and limits gives enough context for an agent to understand the tool's purpose.

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

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

The tool has zero parameters, so there is no schema burden. The description adds meaning by clarifying what is being read (credits used/reserved and limits) and that there is no credit cost, which is useful for an agent deciding whether to call it.

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

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

The description clearly states the tool reads free beta credits used/reserved and limits, with a specific verb ('Read') and resource ('Free beta credits used/reserved and limits'). It is distinct from sibling tools, which are all document/job operations, so an agent can easily tell this is a usage/account query tool.

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

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

The description implies this is a read-only query tool for checking usage/limits, and the sibling list confirms it is the only usage-related tool. It doesn't explicitly state when to use it vs alternatives, but the context makes it clear there are no real alternatives for this purpose.

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

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

The description discloses meaningful side effects beyond the annotations: a 10-credit cost on success, a 5 MB upload limit, a 100-page output limit, and a layout-quality caveat. It does not contradict the annotations and adds practical behavioral detail that helps the agent anticipate consequences.

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

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

Three short sentences deliver the action, constraints, cost, and follow-up guidance with no filler. The most important information is front-loaded, and every sentence earns its place.

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

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

The description covers input types, cardinality, size/page limits, and cost, but it does not explain the role of requestId or how the resulting PDF is returned or stored. Since there is no output schema, a bit more detail about the output artifact would make the tool fully self-sufficient.

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

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

The description adds useful semantics for fileIds by clarifying that it refers to one uploaded Office file in DOCX, XLSX, or PPTX format. However, requestId is not explained at all, and with 0% schema description coverage, the description only partially compensates for the missing parameter guidance.

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

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

The description uses a specific verb ('Convert') and resource ('one uploaded DOCX, XLSX or PPTX'), and the tool name makes the PDF output unambiguous. It is clearly distinct from the sibling PDF-processing tools, which operate on existing PDFs rather than converting Office files.

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

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

The description provides clear usage context: input must be a single uploaded Office file, and it states size/page limits and the need to check layout after conversion. It does not explicitly name alternatives or exclusions, but no sibling tool offers equivalent Office-to-PDF conversion, so the context is sufficient.

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

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

The description goes far beyond the annotations by disclosing that image quality is unchanged, size reduction is not guaranteed, costs are incurred per started 10 pages, output expires in 10 minutes, and digital signatures can be invalidated. These are non-obvious consequences an agent needs before invoking the tool. There is no contradiction with the annotations.

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

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

The description is compact: four short sentences, each adding a distinct operational fact. The primary verb and resource are front-loaded, and there is no filler or redundant restatement of the tool name.

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

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

For an operation with 7 parameters and no output schema, the description leaves important gaps: how the output is returned or retrieved, what the optional parameters do, and whether all fileIds are processed or only one. Cost and side effects are covered, but an agent cannot fully understand invocation semantics from the description alone.

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

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

Schema description coverage is only 14%, yet the description explains none of the concrete parameters beyond indirectly noting page limits. fileIds, pages, degrees, title, author, and subject are left unexplained, and saying 'one PDF' while fileIds allows up to 10 items creates ambiguity. The description does not compensate for the sparse schema.

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

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: 'Losslessly rewrite one PDF with object streams.' It adds decisive scope details—image quality unchanged and no size-reduction guarantee—that make it distinguishable from sibling operations like pdf_merge, pdf_split, and pdf_rotate.

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

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

The description supplies operational constraints such as credit cost, 100-page maximum, and 10-minute output expiry, which help an agent decide whether the operation is feasible. However, it never explicitly states when to prefer this tool over a sibling, nor does it name alternatives or exclusions; the compression use case is implied but not stated.

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

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

Annotations already mark idempotent and non-destructive; the description adds cost model, 10-minute output expiry, and signature invalidation. These are meaningful beyond the annotations. No contradiction.

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

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

Three sentences, no filler, core action first followed only by operationally relevant constraints. Every sentence contributes.

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

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

The tool has seven parameters and no output schema, yet the description says nothing about the output format/retrieval, the effect of omitting 'pages', or how fileIds maps to 'one PDF'. The cost/expiry details help, but an agent is left with significant gaps.

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

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

Schema description coverage is only 14%, so the description must compensate for the six undocumented parameters. The phrase 'one-based pages order' adds meaning to pages, but fileIds, title, author, degrees, and subject receive no explanation.

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

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

The description uses a specific verb ('extract') and resource ('one PDF') and mentions the page-order parameter. It is clear enough on its own but does not explicitly distinguish it from siblings like pdf_split or pdf_rotate.

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

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

The description implies the tool is for extracting a subset/ordering of pages from one PDF, but it never states when to use it over pdf_split or pdf_rotate, nor any exclusions. There is no 'when not to use' guidance, so an agent must infer.

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

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

The description goes well beyond the annotations by disclosing a precise cost model ('1 credit per started 10 total input pages'), the 100-page maximum, the 10-minute output expiration, and the side effect that rewriting can invalidate digital signatures. These are meaningful operational behaviors an agent needs to know.

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

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

The description is three sentences, front-loaded with the core action, then follows with high-value constraints and warnings. Every sentence contributes operational information without filler.

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

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

Given seven parameters, no output schema, and low schema coverage, the description is not complete enough. It does not explain how to retrieve the merged output beyond saying it expires, nor does it describe the roles of pages, degrees, title, author, and subject. It also says 'at least two PDFs' while the schema allows minItems 1 for fileIds, which could confuse an agent.

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

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

With only 14% schema description coverage, the description needed to compensate, but it only clarifies fileIds order and indirectly references page limits. Parameters like pages, degrees, title, author, and subject receive no semantic explanation in either the description or the schema. This is a significant gap for correct invocation.

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

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

The description opens with 'Merge at least two PDFs in fileIds order,' a specific verb and resource with an explicit ordering constraint. It clearly differentiates this tool from siblings like pdf_split and pdf_rotate, and the naming plus description leave no ambiguity about its function.

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

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

The description implies usage for combining PDFs and states prerequisites (at least two PDFs, the meaning of fileIds order). However, it does not explicitly discuss when to prefer this tool over alternatives such as office_to_pdf or pdf_extract, nor does it provide exclusions or alternative routing.

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

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

The description adds substantial behavioral context beyond the annotations: credit cost per started 10 pages, a 100-page cap, 10-minute output expiry, and potential digital signature invalidation. This goes well beyond the minimal readOnly/destructive hints and gives the agent important operational expectations.

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

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

The description is compact and front-loaded: the purpose appears first, followed by concise, non-redundant sentences about limitations, cost, expiry, and side effects. Every sentence adds distinct value, with no filler or repetition.

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

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

For a tool with 7 parameters, no output schema, and only 14% schema description coverage, the description is incomplete. Critical semantics for 'degrees' and 'pages' are absent, and the 'one PDF' phrase conflicts with the array of up to 10 fileIds. The cost and expiry details are helpful, but not sufficient for confident invocation.

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

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

Schema description coverage is only 14%, so the description must compensate, but it only reuses the names title, author, and subject. It fails to explain 'degrees' (rotation), the meaning of 'pages', or how fileIds relates to the stated 'one PDF' scope. It does add a page-limit and cost constraint, but that is not enough to clarify the undocumented parameters.

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

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

The description identifies a specific action and resource: 'Set title, author or subject on one PDF.' It also distinguishes itself by explicitly stating it is not redaction or metadata sanitization. However, it omits the rotation-related 'degrees' parameter and says 'one PDF' while fileIds allows up to 10, so scope is not fully accurate.

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

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

The description gives an implied usage by naming the metadata fields, and it provides one when-not instruction: 'This is not redaction or complete metadata sanitization.' It does not explicitly route to alternatives or explain when to prefer pdf_rotate, pdf_extract, or other sibling tools, but the core use case is inferable.

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

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

The description adds valuable behavior beyond annotations: credit cost, 100-page input limit, 10-minute output expiration, and the warning that rewriting can invalidate digital signatures. This is especially useful because readOnlyHint=false and destructiveHint=false do not fully convey the mutating side effects.

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

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

Four short sentences, each earning its place: purpose, cost/limit, expiration, and side-effect warning. Information is front-loaded and there is no filler or redundancy.

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

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

The description covers important operational context like cost, limits, expiration, and signature invalidation. However, with no output schema it does not describe the return value or where the rotated file is delivered, and several parameters remain semantically undocumented.

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

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

Schema coverage is only 14%, so the description must compensate, but it only lightly maps 'degrees' and 'pages' without specifying allowed values or formats. It does not explain fileIds, requestId, title, author, or subject semantics, leaving most parameters dependent on the raw schema.

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

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

The description states a specific operation ('Rotate one PDF clockwise by degrees') and resource ('one PDF'), and clarifies the optional scope ('pages selects a subset'). This clearly distinguishes pdf_rotate from sibling tools like pdf_merge, pdf_split, and pdf_compress.

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

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

The description makes the use case clear: rotate a single PDF by a specified angle, optionally on selected pages. It does not explicitly name alternatives or exclusions, but no sibling tool competes for the same operation, so the context is sufficient.

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

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

The description discloses cost (1 credit per 10 started pages), max input pages (100), output expiry (10 minutes), and a side effect (signature invalidation). Annotations only cover read-only, destructive, and idempotent hints, so this adds substantial operational context beyond structured data. No contradiction with annotations.

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

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

Three concise sentences front-load the core purpose, then cover cost and limits, then side effects. Every sentence adds essential information with no filler or redundancy.

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

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

While operational details like cost, expiry, and signature invalidation are covered, the meaning of 7 parameters is largely unexplained, and the workflow (e.g., needing fileIds from upload_document) is absent. With no output schema and minimal schema descriptions, this is a significant gap for correct invocation.

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

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

Schema description coverage is only 14%, with requestId being the only documented parameter. The description does not explain fileIds, pages, degrees, title, author, or subject. An agent cannot determine what values to pass for most parameters from the description.

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

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

The description states a specific verb and resource: 'Split one PDF into a ZIP containing one PDF per page.' This clearly differentiates it from siblings like pdf_merge and pdf_extract. The output format and granularity are unambiguous.

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

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

The tool's purpose implies usage when one PDF per page is needed, but there is no explicit guidance on when to choose it over alternatives like pdf_extract or pdf_merge. No when-not conditions or prerequisite steps are mentioned. It is adequate but relies on inference.

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

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

Annotations only indicate this is not read-only and not destructive, so the description adds valuable behavior: temporary server memory, 10-minute expiration, and the no-external-URL constraint. It does not contradict the annotations and meaningfully discloses lifecycle behavior.

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

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

Three tight sentences with no filler: purpose, consent precondition, expiration, large-file guidance, and URL restriction are all packed efficiently. Each sentence earns its place.

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

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

The description covers consent, expiry, endpoint preference, and URL restrictions, which is strong for invocation. However, with no output schema and no mention of return values or how the uploaded document is referenced by sibling tools like download_document, an agent is left guessing about post-upload behavior.

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

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

Schema description coverage is 0%, so the description must compensate for explaining parameters, but it never names or explains base64, extension, or consentToUpload. It indirectly hints that base64 must contain raw document data by rejecting external URLs, but this is insufficient given the complete lack of parameter descriptions in the schema.

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

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

The description clearly identifies the action (upload), the resource (document to PaperLumo temporary server memory), and the key precondition (user consent). It also differentiates this tool from siblings like delete_document and download_document by focusing on the upload action and temporary nature.

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

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

The description provides clear context: use after user consent, for temporary storage, and not for external URLs. It also gives explicit guidance to prefer the binary /api/mcp/files endpoint for large files, though it does not mention sibling tools as alternatives.

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