Skip to main content
Glama
okra-project

okraPDF PDF MCP server

Official
by okra-project

Draft Workflow

draft_workflow

Create and persist PDF processing workflows. Author agent scripts for custom extraction, A/B tests, and human review, or choose a staff catalog template. Optionally run immediately.

Instructions

Author, create, build, or draft a workflow. For custom/agentic work, pass code as a high-level agent workflow script using agent() / parallel() / pipeline() / phase(). Minimal working code: phase("Extract"); const result = await agent("Extract the invoice total.", { label:"extract", schema:{ type:"object", required:["total"], properties:{ total:{ type:"string" } } } }); return { result };. Each agent call must include a task prompt and a JSON Schema under the schema key, e.g. agent("task", { label:"extract", schema:{ type:"object", required:["rows"], properties:{ rows:{ type:"array" } } } }) or agent({ prompt:"task", label:"extract", schema:{...} }). Plain JS acts as the deterministic controller. This is the path for provider A/B tests, N-provider parser fan-out, judge/compare barriers, and human review via an explicit detect/apply phase split. definition and catalog_workflow_id are only for finite catalog pipelines. Returns workflow_id, readiness, blueprint, and AST when available. Persisted to your account — same as POST /v1/workflows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
runNoStart a run immediately after creating when the selected runtime is configured.
codeNoHigh-level agent workflow script. Author in the agent()/parallel()/pipeline()/phase() grammar. Minimal working script: phase("Extract"); const result = await agent("Extract the invoice total.", { label: "extract", schema: { type: "object", required: ["total"], properties: { total: { type: "string" } } } }); return { result }; Every agent step MUST include a `schema` JSON Schema contract: agent("task prompt", { label: "extract", schema: { type: "object", required: ["rows"], properties: { rows: { type: "array" } } } }) or agent({ prompt: "task prompt", label: "extract", schema: {...} }). The contract key is `schema`; do not use returns/output_schema/json_schema. Barriers are explicit with parallel(() => agent(...)) thunks; pipeline(items, mapper) is sequential by default and can fan out over runtime data with { concurrency }. phase() names the user-visible stage, and human review is modeled as a detect/apply phase split. Use this for provider A/B tests, N-provider parser fan-out, judge/compare barriers, redaction/extraction review, and other custom agent work. The script is captured as the workflow source artifact and runs through the hosted JS controller harness when the runtime bindings are configured.
nameNoHuman-readable workflow name.
inputsNoRun inputs, e.g. { files: ["doc-…"] } for invoice extraction or { document_id: "doc_…" } for an agent workflow. Setting this implies run:true.
definitionNoFinite catalog pipeline only: { steps: [{ type, id?, name?, with?, needs? }] } using GET /v1/steps types. Use this for staff/catalog pipelines, not custom agent work.
catalog_workflow_idNoInstantiate a staff template as your own workflow (e.g. staff.invoice-extraction, staff.table-ingest).
Behavior5/5

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

The description discloses key behavioral traits: the script is 'captured as the workflow source artifact' and 'runs through the hosted JS controller harness,' requires runtime bindings, persists to the user's account, and returns `workflow_id`, `readiness`, `blueprint`, and `AST` when available. It also explains execution semantics like `parallel(() => agent(...))` for barriers and `pipeline(items, mapper)` for fan-out. Annotations are minimal (all false), so this detailed disclosure carries the full transparency burden, and it succeeds.

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 long but densely packed with valuable information, including a minimal working code example and a second `agent()` call example. The structure is front-loaded with the core purpose and key decision points. It loses a point for some redundancy—the full code example appears in both the description and the `code` parameter's schema description—making it slightly more verbose than necessary, but the complexity of the tool justifies most of the length.

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 complex workflow-creation tool with six parameters, nested objects, and no output schema, the description covers all necessary bases: parameter usage, execution environment, persistence, return values, and distinguishing between agentic and catalog modes. It includes explicit guidance on the `schema` contract and how to model human review, making it highly complete for an agent to select and invoke the tool correctly.

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?

Although the schema descriptions cover all six parameters, the tool description adds significant semantic context beyond them. For example, it explains that `inputs` implies `run: true`, that `code` is authored in a specific grammar (with examples and a required `schema` key), and that `definition` is for staff/catalog pipelines only. This enriches parameter understanding and directly informs invocation choices, exceeding the baseline for high schema coverage.

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 'Author, create, build, or draft a workflow,' providing a clear action and resource. It immediately distinguishes two modes: custom agentic work via `code` versus finite catalog pipelines via `definition`/`catalog_workflow_id`, which differentiates it from siblings like `run_workflow` and `view_workflow`. The explicit mention of use cases (A/B tests, parser fan-out) further sharpens its purpose.

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 explicitly states when to use `code` ('For custom/agentic work') and when to use `definition`/`catalog_workflow_id` ('only for finite catalog pipelines'), including a contrast between the two. It also provides a minimal working example and detailed constraints on `agent()` calls, effectively guiding the agent on selection and invocation. This goes well beyond implicit usage hints.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/okra-project/pdf-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server