Dreamwork MCP Server

Official

by dreamworkhq

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Get a link to the person's resume

get_resume_download_link

Read-only

Generate a temporary, login-free download link for the account's main profile resume PDF, with expiry, filename, and MIME type. Use it to share the existing resume file without returning content.

Instructions

Returns a download link for the account's main profile resume as a PDF, with its expiry, filename and MIME type. The link opens without login for ten minutes and only for the file that existed when it was made. It returns no file content. status is ready, no_resume_on_file or no_file_for_resume; the last two carry null fields and are not errors.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`url`	Yes
`status`	Yes	`ready` carries the link. The other two mean there is nothing to link to, and every other field is null.
`filename`	Yes
`mimeType`	Yes
`expiresAt`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 14, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Adds rich context beyond annotations: link expiry (ten minutes), no-login access, immutability ('only for the file that existed when it was made'), no file content, and detailed status values with non-error explanations. Annotations flag read-only/non-destructive, but the description covers operational behavior fully.

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?

Three sentences, front-loaded with the core purpose and key constraints. Every sentence adds essential 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?

Complete for a zero-param, read-only tool with an output schema. The description covers link expiry, access constraints, immutability, content absence, and status values, leaving no ambiguity for correct invocation or interpretation.

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?

Zero parameters, so baseline is 4 per guidelines. The description appropriately focuses on output semantics and doesn't need to discuss params.

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 (returns) and resource (download link for profile resume as PDF), and clarifies scope: 'main profile resume.' Distinguishes from siblings like get_profile, upload_resume, and edit_resume by narrowly defining it as link generation, not fetching content.

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

Usage Guidelines4/5

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

Implies when to use by distinguishing it from content retrieval ('It returns no file content'), which is useful against siblings like get_profile that might return resume data. However, it doesn't explicitly name alternative tools or when-not scenarios beyond that.

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

Deploy Server