Skip to main content
Glama

Heista

by co.heista

Create PowerSource from Documents

create_powersource_docs

Build a complete creative intelligence profile from internal brand documents — creative briefs, brand guidelines, product specs, customer research, competitive analysis. Takes any mix of file_ids (from a previous upload), document_urls (public PDF/DOCX/TXT/MD links, up to 10), or documents_inline (base64-encoded files with filename), plus an optional context_url for layering live brand context (colors, fonts, current messaging) and optional idempotency_key. Returns a job_id; poll with get_powersource. Output shape is identical to create_powersource_url: identity, offer, selling points, voice, buyer profile, tensions, angles, emotional arcs, ctas, narrative.

Use this when the user says "I have a brief", "here's my brand guidelines", "use this document", drops a PDF / DOCX / strategy deck, or when the truth lives in internal materials rather than the public website. The pipeline reads text only — convert PDFs to markdown before submitting via documents_inline when possible.

Costs 100 credits.

Do NOT use for URL-only scans — use create_powersource_url. For URL + docs combined (highest fidelity, triangulates public messaging against internal strategy), use create_powersource_full.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
brand_idNoOptional Brand to attach this scan to. Get from list_brands. When omitted, the pipeline auto-resolves a brand by the context_url domain (if provided) or creates a standalone scan with no brand link.
file_idsNoArray of file IDs from a previous upload. Up to 10 files.
context_urlNoOptional website URL to layer live brand context on top of the documents (colors, fonts, current messaging).
document_urlsNoArray of public URLs pointing to documents (PDF, DOCX, TXT, MD). Up to 10 URLs.
idempotency_keyNoOptional unique key to make this call safely retryable. If the same key + org repeats, the original result is returned without re-charging.
documents_inlineNoInline documents as base64. Use when the user has uploaded a file into chat and no public URL exists. IMPORTANT: The synthesis pipeline reads TEXT ONLY — it ignores images, diagrams, and visual layout. For any PDF or DOCX the user drops into chat: (1) read the file using your file-reading tools, (2) extract the text content preserving section headers and structure, (3) save as a clean .md or .txt file, (4) base64-encode the text file and submit here. Do NOT base64-encode the original PDF — extract text first. This keeps payloads small (a 50-page brief extracts to ~50KB of text vs 5MB of PDF) and produces better results because the pipeline gets clean structured text instead of OCR-extracted noise from embedded images. Max 5MB per file, 10 files total across all input types.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations provide readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, which are consistent with a creation tool. The description adds rich behavioral context: it returns a job_id for polling, costs credits, reads text only, and gives instructions for handling PDFs. 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.

Conciseness4/5

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

The description is fairly long but well-structured with clear paragraphs. It front-loads the main purpose and lists input options concisely. The detailed instructions for documents_inline are necessary given the complexity, but could be slightly trimmed without losing value. Overall, every sentence serves a purpose.

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?

Given the complexity (6 parameters, multiple input types, nested objects in documents_inline, no output schema), the description is remarkably complete. It covers all input types (file_ids, document_urls, documents_inline), explains the text-only pipeline, provides polling instructions, lists the output structure (identity, offer, etc.), and gives clear usage guidance. No gaps identified.

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

Parameters5/5

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

Schema coverage is 100% with descriptions for all 6 parameters. The description significantly adds value beyond the schema, especially for 'documents_inline': it explains the text-only pipeline, how to extract text from PDFs/DOCX, base64 encoding limitations, and why this improves results. For 'brand_id', it explains auto-resolution behavior. Other parameters like 'idempotency_key' and 'context_url' are also well-explained.

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 clearly states the tool's purpose: 'Build a complete creative intelligence profile from internal brand documents'. It specifies the verb (build/create), the resource (powersource), and the input type (documents). It distinguishes from siblings by explicitly stating when to use create_powersource_url and create_powersource_full, and provides examples of user utterances that trigger this tool.

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?

The description provides explicit usage scenarios: 'when the user says "I have a brief", "here's my brand guidelines", "use this document", drops a PDF / DOCX / strategy deck, or when the truth lives in internal materials'. It also clearly states when NOT to use it ('Do NOT use for URL-only scans') and points to the correct sibling tools. Additionally, it mentions the cost (100 credits) and the polling mechanism.

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

All Heista toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation4/5

Despite the high tool count, most tools have distinct purposes with thorough descriptions that specify when to use each. Some overlap exists among creative direction tools (call_creative_worlds vs chat_with_creative_worlds), but the descriptions clarify usage patterns.

Naming Consistency3/5

Naming conventions are inconsistent overall: some follow verb_noun (create_powersource_url, decode_ad), others use noun_verb or compound names (adformula_intelligence, fleet_analytics_overview). However, subgroups like dispatch_* and list_*_presets maintain internal consistency.

Tool Count2/5

112 tools is far beyond the typical 3-15 range for well-scoped servers. While the server covers a broad domain, the sheer number likely overwhelms agents and suggests insufficient consolidation of related operations.

Completeness4/5

The tool set covers core creative intelligence workflows: brand analysis, ad decoding, script generation, creative direction, and research. Minor gaps exist (e.g., no social media publishing tools), but the main use cases are well-supported.

Resources