DEV Community: Kozo-KI

Building a Technical Literature Dashboard with Power Automate Power Apps LDX hub StructFlow

Kozo-KI — Mon, 18 May 2026 23:51:51 +0000

Verification Case Report #006 — 2026.05.18 | Time spent: ~3 days

Overview

Metric	Value
Documents processed	18
Power Apps screens	4
Power Automate flows	2
StructFlow extracted fields	8

We built TechLit Viewer — an end-to-end technical literature management system that uses LDX hub StructFlow to extract structured data from documents, Power Automate to keep everything updated, and both Power Apps and a standalone HTML dashboard for visualization.

Background

Many customers express a need to continuously collect and evaluate technical literature across diverse fields. The old approach — storing PDFs and patent documents in folders — made it nearly impossible to answer questions like "which technologies are at which maturity level?" or "which documents are most relevant to our business?"

We set out to verify whether a practical technical literature management system could be built within a no-code/low-code stack by combining LDX hub StructFlow for AI extraction with Microsoft 365 tools for storage, automation, and display.

What we're testing: Can StructFlow turn unstructured technical documents (PDFs, patents, reports) into structured data that integrates cleanly with SharePoint, Power Automate, and Power Apps?

System Architecture: 5 Layers

// TechLit Viewer — System Overview

[1] INPUT         Source files (PDF / patents / reports)
                  └─ Stored in SharePoint document library. 18 documents total.

[2] AI EXTRACTION LDX hub StructFlow
                  └─ Auto-extracts 8 fields:
                     Title / DocType / Authors / Year / FieldMajor /
                     TRL / RelevanceScore / Summary

[3] DATA LAYER    SharePoint Lists (TechLit_Master / TechLit_Metrics)
                  └─ Power Automate writes; Power Apps + HTML dashboard reads.

[4] AUTOMATION    Power Automate (2 flows)
                  └─ ① Auto-extract on item update  (TechLit_Pipeline_UPDATE)
                     ② Manual bulk processing       (TechLit_BulkUpdate)

[5] DISPLAY       Power Apps (TechLit_Viewer) + HTML dashboard
                  └─ 4-screen Power Apps + standalone HTML dashboard

Flow Design: Two Flows for Two Purposes

① TechLit_Pipeline_UPDATE (always-on)

Fires automatically when a SharePoint list item is updated. Detects new document registrations or changes to existing records, sends the file to StructFlow, and immediately writes the extracted results back. Day-to-day document additions are fully automated via this flow.

② TechLit_BulkUpdate (manual trigger)

A manual-trigger flow for bulk processing all 18 documents. Used after schema changes, prompt revisions, or for initial data loading. Iterates through all items with a foreach loop, waits for StructFlow polling to complete, and writes results back to the list.

Key design insight: The update trigger excels at immediacy but isn't suited for full reprocessing. The manual trigger handles bulk operations well but requires operator action. Using both flows together covers both daily operations and administrative tasks.

StructFlow Extraction Schema: 8 Fields

Schema design started from the question: "what do we want to decide?" — not "what can we extract?"

Field	Description	Type
Title	Document title	string
DocType	Document type (patent / paper / report / other)	string
Authors	Authors / applicants	string
Year	Publication / filing year	integer
FieldMajor	Primary technology domain (Materials Science, Energy Engineering, etc.)	string
TRL	Technology Readiness Level (1–9)	integer
RelevanceScore	Relevance to our business (high / medium / low)	string
Summary	2–3 sentence technical summary	string

About TRL (Technology Readiness Level): Originally developed by NASA and adopted by EU Horizon programs. Levels 1–3 = basic research, 4–6 = demonstration, 7–9 = operational/production. Quantifying maturity makes it easy to distinguish research-stage from production-ready technologies at a glance.

Power Apps: 4 Screens for Different Use Cases

Screen	Features
Screen 1: Search	Free-text search by title, author, or domain. Filtering by DocType, TRL, RelevanceScore. Real-time queries against SharePoint list.
Screen 2: Detail View	Full field display for individual documents. Review StructFlow-extracted Summary. Visual TRL and relevance indicators.
Screen 3: Metrics Comparison	TRL distribution by technology domain. Document count by relevance. Year-over-year trend charts.
Screen 4: Tech Dashboard	Advanced visualization via embedded HTML component. Dynamic charts with Chart.js. Integrated full-text search over all 18 documents.

HTML Dashboard: Standalone Strategic View

Alongside Power Apps, we built a standalone HTML dashboard (techlit_dashboard.html) that runs entirely in the browser — no Power Apps dependency. This makes it easy to share with executives or external stakeholders.

// StructFlow extraction results stored directly as a data array
const data = [
  {
    id: 17,
    title: 'Immobilized Photocatalyst Paper',
    docType: 'patent',
    authors: '[Author name masked]',
    year: 2002,
    fieldMajor: 'Chemistry',
    trl: 4,
    relevance: 'high',
    url: ''  // SourceFileUrl — will become a live link once populated
  },
  // ... 18 documents total
];

The dashboard includes 4 charts (technology domain distribution, TRL distribution, year-over-year trend, document type breakdown) plus a searchable full-document table. Passing StructFlow's structured data to Chart.js generates all analysis charts automatically.

Results

StructFlow Extraction Accuracy

15 of 18 documents (83%) had all fields extracted correctly. The remaining 3 showed mixed-language inconsistencies in FieldMajor (English vs. Japanese) — no impact on usability, but a clear prompt improvement opportunity.

Power Automate Automation

Average processing time per document: ~67 seconds (including StructFlow polling). Full run of all 18 documents: ~20 minutes. Both scheduled and trigger-based execution confirmed stable.

Technology Domain Visibility

Environmental Science was the largest category (6 documents), followed by Materials Science (4). TRL distribution: basic research (1–3) was highest at 8 documents; operational stage (7–9) had 3. For the first time, we had a quantitative picture of the entire portfolio.

Relevance Scoring

15 of 18 documents scored RelevanceScore = High. By embedding our business context (translation & localization) into the StructFlow system prompt, we achieved automatic screening aligned with our actual evaluation criteria.

Biggest insight: from "searching" to "discovering"
Technical documents that could previously only be searched by filename can now be filtered across TRL, technology domain, and relevance simultaneously. Being able to instantly narrow down to "TRL ≥ 4 AND Materials Science AND High relevance" fundamentally changes the speed of technology strategy decisions.

Lessons Learned

1. Lock down SharePoint column types before you start

Column types (hyperlink vs. single line of text) can't be changed after the fact. Confirm the format Power Automate will write, then finalize column design before building.

2. Design the StructFlow schema from your decision criteria

Don't start from "what can we extract?" — start from "what do we need to decide?" Including evaluation-axis fields like TRL and RelevanceScore from the beginning dramatically increases dashboard value.

3. Separate Power Apps and HTML dashboard by purpose

Power Apps suits day-to-day search and update operations; the HTML dashboard suits sharing and presentations. Using two UIs on the same data source expands both the audience and the use cases.

4. Control FieldMajor normalization via the prompt

Mixed English/Japanese values like "Materials Science" and "材料科学" split aggregations. Adding an explicit instruction to the StructFlow system prompt ("always output technology domains in English") prevents this drift.

Next Steps

Item	Details
Populate SourceFileUrl	Add source URLs to the SharePoint list so users can reach original documents in one click from the dashboard
Schedule automation	Move from manual triggers to fully automated monthly runs with auto-distribution to leadership
Normalize FieldMajor	Add English-only instruction to StructFlow prompt and reprocess all 18 documents
Scale to 100+ documents	Add ExtractDoc as a pre-processing step to handle scanned PDFs
RefineLoop integration	Auto-translate and improve summaries of foreign-language documents (English, Chinese) into Japanese

Kawamura International is a translation and localization company documenting its AI process experiments in public. StructFlow, RefineLoop, RenderOCR — and whatever comes next.

We fed meeting minutes to AI without structure — and lost 70% of the data we needed for decisions

Kozo-KI — Wed, 13 May 2026 04:23:06 +0000

I'm Kozo Moriguchi, CEO of Kawamura International.

We started in translation and localization, moved into MT SaaS, and now I'm focused on building out the LDX business. I'm not an engineer — but I test and rebuild business processes with AI, and I write about what actually happens.

This is Part 5 of that series. The question this time: can you build a reliable management dashboard by just handing your meeting minutes to an AI?

The context: most companies can only use Copilot

When you try to bring AI into enterprise workflows, you hit a wall quickly.

Many organizations — due to security policies or vendor agreements — restrict which AI tools employees can use. Claude, ChatGPT: blocked. Copilot: allowed. I've seen this pattern repeatedly across companies we work with.

That's why I ran this test. If Copilot is all you have, what can it actually do? And how does it compare to using LDX hub StructFlow to extract structured data first?

I used 20 departments worth of real meeting minutes and ran both approaches on the same data.

What we tested

Copilot approach
Paste meeting minutes into Microsoft Copilot. Ask it to organize the data into an HTML management dashboard. No schema defined. Let Copilot decide what's important.

StructFlow approach
Define a schema upfront (tasks, risks, cross-department requests as structured JSON). Run StructFlow via LDX hub API. Use Power Automate to generate an HTML dashboard with Chart.js charts. Save to SharePoint. Return the URL to Copilot Studio.

Same input data. Same goal. Different method.

See the dashboards yourself

Rather than just describing the difference, here are both dashboards built from the same 20-department dataset.

Copilot-generated dashboard (sample)
👉 Open dashboard

Copilot + LDX hub StructFlow dashboard (sample)
👉 Open dashboard

These pages are unlisted (no-index) and contain no real company data. URL access only.

Looking at them side by side, the difference in information density becomes immediately visible — before you even look at the numbers below.

The numbers

Metric	StructFlow	Copilot	Difference
Tasks extracted	100	18	-82
Risks extracted	45	~16	Significantly fewer
Cross-dept requests	83	~17	-66
High-severity risks	21	6	-15
Departments processed	20/20	20/20	Same

From the same 20 departments of meeting notes:

5.5× more tasks extracted with StructFlow
2.6× more risks surfaced
4.9× more cross-department dependencies identified

Copilot didn't fail to read the documents. It read them, summarized them, and produced a polished HTML output. But in the process of summarizing, an enormous amount of information was compressed away.

What specifically got dropped

The quantitative gap is significant. But what matters more is what fell through.

Here's what Copilot's dashboard was missing that StructFlow caught:

① Operations team overload — 3 simultaneous cases, high attrition risk
StructFlow: extracted as 3 separate structured task items with named assignees and risk flags.
Copilot: compressed to "resource reallocation needed."

② Finance team: M&A accounting and audit response
StructFlow: specific tasks with deadlines.
Copilot: not mentioned.

③ Partner team: top 3 partners = 70% of revenue (concentration risk)
A significant business continuity risk.
Copilot: not mentioned.

④ QA team: 2 security vulnerabilities
StructFlow: extracted as independent risk items.
Copilot: buried in another department's section.

⑤ Facilities: monthly office rent at ¥32M
A concrete cost figure.
Copilot: omitted entirely.

The dangerous part isn't that these were summarized — it's that you wouldn't know they were missing. Looking at a clean Copilot-generated dashboard, there's no indication that any of this exists. The gap only became visible when we had the StructFlow version to compare against.

Why "just ask the AI" fails structurally

There are four structural reasons why unstructured AI extraction breaks down for management reporting:

1. Summarization pressure
LLMs are optimized to produce readable output. Given a long document, they compress it using their own judgment about what matters. That judgment is based on training data — not your company's priorities.

2. No consistent format = no trend analysis
Copilot's output format changes every run. If last month's dashboard has different columns than this month's, you can't track trends. A management dashboard needs consistent structure by definition.

3. You can't see what's missing
This is the most dangerous failure mode. A well-formatted summary looks complete. You only discover the gaps when you have a structured comparison. In practice, most teams would never run both approaches side by side — so the gaps stay invisible.

4. Doesn't scale
StructFlow processes 20 departments at the same cost as 5. Ask Copilot to handle 30 departments in one prompt and output quality degrades. The approaches scale in opposite directions.

Where Copilot genuinely wins

To be fair: Copilot has real strengths.

KPI snapshots — organizing revenue, churn rate, and utilization into a summary view is something Copilot does quickly and well.
Design quality — the HTML output looks polished. Good for executive presentations.
Narrative context — Copilot understands "A company deal → technical proposal → executive meeting" as a sequence. It writes it as a coherent story.

The honest summary:

For "quickly get a sense of things before a meeting" → Copilot
For "make sure nothing critical is missed" → StructFlow

These aren't competing tools. They serve different purposes.

The pipeline that's running now

Here's the StructFlow setup we built:

Meeting minutes (SharePoint files)
    ↓
Power Automate (batch processing flow)
    ↓
LDX hub StructFlow API (JSON structured output)
    ↓ polling every 3 seconds (Do Until)
HTML dashboard generation (with Chart.js)
    ↓
Saved to SharePoint → URL returned to Copilot Studio
    ↓
User views in browser

The key piece: Power Automate's "Create file" action writes the full HTML (including <script> tags) to SharePoint as a static file. Chart.js runs fine in that context. Copilot Studio returns the URL to the user.

Total setup time from zero: about 3 hours, including all the wrong turns.

What's next: multilingual dashboards

LDX hub has another API alongside StructFlow: RefineLoop.

RefineLoop is designed for translation quality refinement. But combined with StructFlow, it opens up an interesting use case: companies with global operations often have meeting notes in multiple languages — English, Japanese, Spanish, Mandarin. StructFlow extracts structured data from each. RefineLoop normalizes and quality-checks the translation into a unified language. The result: a single dashboard aggregating data from every regional office, regardless of what language their notes were written in.

Given that Kawamura International's roots are in translation and localization, this is a direction we're particularly interested in building out.

Coming up: n8n and Dify

I will run the same test on n8n and Dify.

Power Automate is a Microsoft-native tool. n8n is an open-source workflow automation platform you can self-host. Dify is an LLM app development framework. Same StructFlow API underneath — but the surrounding infrastructure changes. I want to know what that changes in practice.

If you're locked into a Microsoft environment, the setup from this post should work for you. If you have more flexibility, stay tuned for Part 6.

Kawamura International is actively testing AI integration across translation and localization workflows. We publish findings through LDX Lab as we go.

I batch-processed 20 meeting minutes with Power Automate + LDX hub. It took 2 days and 8 HTTP actions.

Kozo-KI — Tue, 12 May 2026 00:19:44 +0000

This is Part 4 of a series documenting a non-engineer CEO's attempts to connect Copilot Studio and Power Automate to LDX hub's StructFlow API.
Part 1 — It didn't work yet. Part 2 — REST API via Power Automate, finally working. Part 3 — MCP direct connection, 2 hours.

In Part 3, I connected LDX hub directly to Copilot Studio via MCP. One record at a time, in a chat interface. It worked great.

But then I asked the obvious question: what about 20 files? Batch processing 20 Word documents from SharePoint, extracting structured data from each, and synthesizing them into a single company-wide dashboard?

That's not a job for MCP. That's a job for Power Automate.

This is the story of building that pipeline — every error, every detour, and the moment it finally worked.

What I built:

Microsoft Power Automate flow
20 Word files in SharePoint
LDX hub ExtractDoc + StructFlow (REST API, not MCP)
Output: HTML management dashboard saved to SharePoint

Time required: ~2 days

Architecture

SharePoint (20 Word files)
  ↓ Get files (properties only)
  ↓ Initialize array variable: results[]
  ↓ Apply to each file:
    ├─ Get file content (by path)
    ├─ POST /uploads → file_id (upload session)
    ├─ PUT /uploads/{file_id} → upload binary (base64)
    ├─ POST /extractdoc/jobs → job_id
    ├─ Do until status = completed (poll GET /extractdoc/jobs/{job_id})
    ├─ GET /files/{output_file_id}/content → extracted text
    ├─ POST /structflow/jobs → job_id
    └─ Do until status = completed (poll GET /structflow/jobs/{job_id})
        → append body to results[]
  ↓ POST /structflow/jobs (cross-dept analysis)
  ↓ Do until status = completed
  ↓ Compose HTML dashboard
  ↓ Create file in SharePoint

8 HTTP actions per file. 20 files. Sequential processing.

The errors, in order

Error 1: Wrong upload endpoint

I started with POST /api/v1/uploads. Got 404.

The correct endpoint (without the /api/v1 prefix) is:

POST https://gw.ldxhub.io/uploads

Lesson: check the API docs directly. The base URL doesn't always include a version prefix.

Error 2: File content — multipart/form-data nightmare

POST /files requires multipart/form-data. Power Automate's HTTP connector doesn't handle this cleanly.

The workaround: use the chunk upload flow instead.

POST /uploads — creates an upload session, returns file_id
PUT /uploads/{file_id} — sends the file content as base64 JSON

{
  "data": "@{base64(body('パスによるファイル_コンテンツの取得'))}"
}

This is the JSON-based chunk upload designed for MCP clients, but it works perfectly from Power Automate too.

Error 3: File not found (SharePoint path)

Getting file content by ID didn't work. The fix: use "Get file content by path" instead of "Get file content".

The correct path format:

concat('/Shared Documents/General/LDXhubtest/', items('それぞれに適用する')?['{FilenameWithExtension}'])

The field name is {FilenameWithExtension} (with curly braces) — found by inspecting the raw output of the "Get files" action.

Error 4: ExtractDoc engine name

"engine": "docx" returned an error. The correct engine ID:

{
  "engine": "ki/extract"
}

Check available engines with GET /extractdoc/engines first.

Error 5: Do until condition syntax

Power Automate's new designer is strict about condition expressions. This fails:

@{body('HTTP_3')?['status']}  equals  completed

This works (in advanced mode):

@equals(body('HTTP_3')?['status'],'completed')

Error 6: ExtractDoc doesn't return text directly

I assumed ExtractDoc would return the extracted text in the response body. It doesn't.

The response contains output_file_id. You then need:

GET /files/{output_file_id}/content

to download the actual text. This requires an extra HTTP action between ExtractDoc polling and StructFlow job creation.

Error 7: Array variable append — null value

AppendToArrayVariable with body('HTTP_5')?['results'] returned a null error.

Fix: append body('HTTP_5') (the entire response), not just the results field.

Error 8: Cross-scope reference error

When I tried to reference loop-scoped actions from outside the loop (for the cross-department analysis step), Power Automate threw:

The action 'HTTP_5' is nested in a foreach scope of multiple levels. 
Referencing repetition actions from outside the scope is not supported.

The solution: accumulate everything into the results array variable inside the loop, then pass variables('results') to the final analysis step outside the loop.

The working flow — key settings

File upload (HTTP)

URI: https://gw.ldxhub.io/uploads
Method: POST
Headers:
  Content-Type: application/json
  Authorization: Bearer {API_KEY}
Body:
{
  "filename": "@{items('それぞれに適用する')?['{FilenameWithExtension}']}"
}

File content upload (HTTP 1)

URI: https://gw.ldxhub.io/uploads/@{body('HTTP')?['file_id']}
Method: PUT
Body:
{
  "data": "@{base64(body('パスによるファイル_コンテンツの取得'))}"
}

ExtractDoc job (HTTP 2)

URI: https://gw.ldxhub.io/extractdoc/jobs
Method: POST
Body:
{
  "engine": "ki/extract",
  "file_id": "@{body('HTTP')?['file_id']}",
  "output_format": "text"
}

Download extracted text (HTTP 8, after polling)

URI: https://gw.ldxhub.io/files/@{body('HTTP_3')?['output_file_id']}/content
Method: GET

StructFlow job (HTTP 4)

{
  "model": "anthropic/claude-sonnet-4-6",
  "system_prompt": "以下の会議議事録から構造化データを抽出してください...",
  "example_output": { ... },
  "inputs": [{"id": "0", "data": {"minutes": "@{body('HTTP_8')}"}}]
}

The result

After 2 days of iteration:

Metric	Result
Departments processed	20 / 20
StructFlow jobs completed	20 / 20
Total tasks extracted	100
High-severity risks identified	21
Cross-department dependency entries	60+

The HTML dashboard shows:

Company-wide task list (all 100, with assignee, deadline, related dept)
Risk cards by severity (color-coded)
Cross-department dependency map
Per-department summary cards

Key insight on architecture: LDX hub handles all the intelligence — text extraction (ExtractDoc) and structured data generation (StructFlow). The HTML template I wrote just renders the JSON. The processing engine and presentation layer are fully separated.

MCP vs REST API — the actual comparison

Now that I've done both, here's the honest breakdown:

	MCP (Part 3)	REST API — Power Automate (Part 4)
Setup time	~2 hours	~2 days
Errors	2	8+
Best for	Single record, interactive	Batch processing
20-file batch	❌ Not practical	✅ Right tool
Polling complexity	Handled by agent	Manual Do until loops
File upload	Via MCP chunk API	Via REST chunk upload

MCP wins on simplicity for conversational use cases. REST API wins for scheduled batch jobs.

What I'd do differently

Test with 1 file before 20. I wasted hours debugging a flow that was running on all 20 files.
Check the API docs before assuming endpoint paths. The /api/v1/ prefix doesn't exist on all endpoints.
Verify Do until conditions in advanced mode. The GUI condition builder generates subtly wrong expressions.
Add error handling. The current flow times out silently if an API call fails mid-loop.

What's Next

Phase 2: A quality comparison between two approaches to dashboard generation:

Structured data route: StructFlow extracts JSON → HTML renders JSON (what we built)
Unstructured data route: raw meeting text passed directly to an LLM → HTML rendered from prose output

The hypothesis: structured data produces more consistent, queryable, and accurate dashboards. But how much better, exactly? And at what cost difference? That's the next experiment.

Kawamura International is a translation and localization company documenting its AI process experiments in public. StructFlow, RefineLoop, RenderOCR — and whatever comes next.

I skipped Power Automate and connected LDX hub directly via MCP. It worked in 2 hours.

Kozo-KI — Sun, 10 May 2026 23:21:01 +0000

This is Part 3 of a series documenting a non-engineer CEO's attempts to connect Copilot Studio to LDX hub's StructFlow API.
Part 1 — It didn't work yet. Part 2 — REST API, 8 errors, 3 hours, finally working.

In Part 2, I got the REST API route working through Power Automate. It took 3 hours and 8 errors. The moment it worked, I immediately wondered: is there a simpler path?

There is. It's called MCP.

Instead of building a Power Automate flow, configuring polling loops, and debugging HTTP connectors — I connected LDX hub's MCP server directly to the Copilot Studio agent. The whole thing took about 2 hours, and most of that was figuring out two non-obvious settings.

Here's the full account.

Environment

Microsoft Copilot Studio (Kawamura International tenant)
LDX hub MCP Server (https://gw.ldxhub.io/mcp)
Existing agent: Minutes Assistant (議事録アシスタント)
Time required: ~2 hours

Why MCP instead of Power Automate?

The REST API route in Part 2 works. But it required:

Building a Do Until polling loop
Debugging HTTP connector confusion (white vs green)
Dealing with triggerBody() reference errors
Managing variable types for async results

MCP eliminates all of that. The agent calls the tool directly — no middleware, no flow to maintain. If the tradeoff is acceptable for your use case, it's a significantly faster path to get running.

The tradeoff: MCP is better suited for interactive, single-record use cases. For batch processing 20 files, Power Automate is still the right answer. More on that in Part 4.

Background

At Kawamura International, we're building generative AI-driven business processes across the company. This verification focused on integrating LDX hub's StructFlow (structured data extraction) into our "Minutes Assistant" Copilot Studio agent — automatically extracting the following from meeting transcripts:

Tasks & action items (with assignee and due date)
Decisions made
Per-speaker summaries
Next meeting agenda candidates

Architecture

User (pastes meeting transcript)
  ↓
Copilot Studio "Minutes Assistant"
  ↓ MCP tools/call (Streamable HTTP)
LDX hub MCP Server (https://gw.ldxhub.io/mcp)
  ↓ createStructFlowJob
StructFlow Engine (async job)
  ↓ getStructFlowJob (polling)
Structured JSON result
  ↓
Copilot Studio formats and responds

Step 1: Verify the Endpoint Before Connecting

Before touching Copilot Studio, verify that the LDX hub MCP endpoint meets the requirements.

⚠️ Important: SSE transport is deprecated after August 2025
Copilot Studio dropped SSE support and now requires Streamable HTTP only. Always verify the protocol before attempting a connection.

Run this in PowerShell to check:

$headers = @{
    "Content-Type"  = "application/json"
    "Accept"        = "application/json, text/event-stream"
    "Authorization" = "Bearer YOUR_API_KEY"
}
$body = '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'

$r = Invoke-WebRequest -UseBasicParsing `
     -Uri "https://gw.ldxhub.io/mcp" `
     -Method POST -Headers $headers -Body $body

Write-Host "Status:"       $r.StatusCode             # → 200
Write-Host "Content-Type:" $r.Headers["Content-Type"] # → application/json
Write-Host "Body:"         $r.Content                 # → protocolVersion: 2025-03-26, 26 tools

What to look for:

Check	Expected	Meaning
HTTP Status	200	Endpoint reachable
Content-Type	`application/json`	✅ Streamable HTTP
protocolVersion	`2025-03-26`	✅ Latest protocol
tools count	26	createStructFlowJob, getStructFlowJob, etc.

If you get HTTP 405 or 404, the server may only support the old SSE transport — which Copilot Studio no longer accepts.

Step 2: Add the MCP Server in Copilot Studio

① Enable Generative Orchestration first

Agent settings → Generative AI → Select "Yes, use available tools and knowledge dynamically".

Without this, MCP tools will never be called — no matter what you configure.

② Add the MCP Tool

Agent → Tools tab → Add a tool → New MCP tool → Fill in the wizard:

Field	Value
Server URL	`https://gw.ldxhub.io/mcp`
Authentication	API Key
API Key value	`Bearer {your_api_key}` ← include the prefix
Header name	`Authorization`

③ Create the connection

Click "Not connected" dropdown → "Create new connection" → Enter the API key → "Create".

A green dot confirms a successful connection.

⚠️ The #1 gotcha: Bearer prefix
The API Key field in Copilot Studio sends the value as-is in the Authorization header. If you enter just the raw key without Bearer, LDX hub returns a 403 error. Always enter Bearer {key}.

Step 3: Add the System Prompt

In the agent's overview tab, paste this into the Instructions field:

You are an assistant that structures meeting minutes.

When the user provides meeting transcript text, always call the
createStructFlowJob tool from LDX hub MCP test to extract:

- Tasks and action items (with assignee and due date)
- Decisions made
- Per-speaker summaries
- Next meeting agenda candidates

After creating the job, poll using getStructFlowJob until status
is "completed", then format and display the results.

Respond in Japanese using tables and lists for readability.

Note: You don't need to manually specify system_prompt or example_output for StructFlow here — the agent's LLM generates those automatically at runtime.

Results

We fed in a real sales team monthly review transcript (5 participants, ~600 characters in Japanese). Here's what came back:

Category	Count	Quality
Tasks & action items	3	✅ Assignees and deadlines accurate
Decisions	3	✅ All correct
Per-speaker summaries	5	✅ Roles and contributions reflected
Next agenda candidates	4	✅ Inferred implicit items too

Confirmed MCP execution via activity log:
The activity log showed "LDX hub MCP — Working / Initialized" with createStructFlowJob and getStructFlowJob call records — confirming that StructFlow was actually invoked via MCP, not just processed by Copilot Studio's internal LLM.

Key Takeaways

1. Verify SSE vs Streamable HTTP before connecting
Copilot Studio dropped SSE after August 2025. Send an initialize request first and confirm protocolVersion: 2025-03-26 in the response.

2. API Key needs the Bearer prefix
The API Key field passes its value directly as the Authorization header value. Omitting Bearer causes a 403 on the LDX hub side.

3. Generative Orchestration must be on
Check this before anything else. It's the gate that controls whether MCP tools get called at all.

4. Verify actual MCP calls via the activity log
You can confirm whether the agent truly called an MCP tool (vs. just using its internal LLM) by checking the activity log. Look for the tool name and "Working" status.

MCP vs REST API: Which should you use?

	MCP	REST API (Power Automate)
Setup time	~2 hours	~3 hours
Errors encountered	2	8
Middleware required	None	Power Automate flow
Best for	Interactive, single-record	Batch processing
20-file batch processing	❌ Not practical	✅ Right tool

For a single record in a chat interface, MCP is the simpler path. For batch processing 20 meeting minutes files from SharePoint — that's Part 4.

What's Next

Part 4: Batch processing 20 meeting minutes files from SharePoint via Power Automate — building a cross-departmental management dashboard as the output.

The MCP route works well for one record at a time. But when you need to process 20 Word files, extract structured data from each, and synthesize them into a single company-wide view, Power Automate is the right tool. That's what we're building next.

Kawamura International is a translation and localization company documenting its AI process experiments in public. StructFlow, RefineLoop, RenderOCR — and whatever comes next.

A non-engineer CEO connected Copilot Studio to LDX hub. It took 8 errors and 3 hours. Here's the full log.

Kozo-KI — Fri, 08 May 2026 01:20:04 +0000

I'm the CEO of a translation company. Not an engineer.

In Part 1, I tried to connect Copilot Studio to LDX hub's StructFlow API and hit a wall before getting anything to work. This is Part 2 — the completion.

It works now.

I pasted meeting minutes into a Copilot Studio chat. It returned structured action items with assignees, tasks, and deadlines. It even interpreted "next week" as a specific date (May 8, Friday) based on the meeting date — and flagged it as an assumption for me to verify.

Here's everything that happened between Part 1 and that result.

The root cause of BadGateway

The HTTP action I'd been using — "Send an HTTP request" — was actually routed through the Office 365 Users connector, not a raw HTTP connector. That's why every request to LDX hub returned BadGateway.

The fix: use the green HTTP connector under "Built-in tools" in Power Automate. It looks similar to the white Office connector but behaves completely differently. The green one makes actual HTTP calls to external APIs.

This distinction isn't obvious from the UI. It cost me most of Part 1.

Switching to Agent Flows

The Power Automate flow I built never appeared in Copilot Studio's tool list, despite being in the same environment. I never resolved why.

The workaround: build the flow directly from Copilot Studio's left sidebar → "Flows" → "Agent flows." This creates a flow that's natively connected to the agent from the start.

Same green HTTP connector, same logic — just a different entry point.

The error log (all 8 of them)

I'm including every error in sequence. Each one moved me closer.

① BadGateway
Cause: Office 365 connector instead of HTTP connector.

② triggerBody()['text']['minutes_text'] cannot be evaluated
Cause: Agent flow triggers have a different body structure than Power Automate triggers.

③ Property 'minutes_text' doesn't exist, available properties are 'text'
Cause: The correct reference is triggerBody()['text'], not nested further.

④ Invalid or missing value for parameter: 'model'
Cause: gpt-4o isn't a valid model ID for LDX hub. The correct format is anthropic/claude-sonnet-4-6.

⑤ Invalid or missing value for parameter: 'example_output'
Cause: example_output is required. I'd omitted it.

⑥ The request body contains invalid or malformed JSON
Cause: The inputs parameter isn't a string — it's an array of objects with a specific schema.

⑦ Property 'output' doesn't exist, available properties are 'results, job_id, ...'
Cause: The results field is called results, not output.

⑧ Variable 'job_status' of type 'String' cannot be updated with value of type 'Array'
Cause: results is an array. The variable holding it needs to be typed as Array, not String. Needed a separate String variable for the status field.

The working request body

{
  "model": "anthropic/claude-sonnet-4-6",
  "system_prompt": "Extract action items from the meeting minutes. Return assignee, task, and deadline in structured format.",
  "example_output": {
    "action_items": [
      {
        "assignee": "Tanaka",
        "task": "Prepare the report",
        "deadline": "End of May"
      }
    ]
  },
  "inputs": [
    {
      "id": "0",
      "data": {
        "minutes": "@{triggerBody()['text']}"
      }
    }
  ]
}

Key differences from what I'd been trying:

inputs is an array of {id, data} objects, not a plain string
model requires the provider-prefixed format: anthropic/claude-sonnet-4-6
example_output is mandatory
triggerBody()['text'] is the correct reference in agent flows

The result

Input: meeting minutes with three action items, including one with a vague deadline ("next week").

Output:

#	Assignee	Task	Deadline
1	Tanaka	Prepare demo environment	May 8, 2026 (Fri)
2	Suzuki	Create job posting	End of May 2026
3	Yamada	Confirm October all-hands schedule	End of June 2026

Note appended by the model: "Next week" was interpreted as May 8 (Friday) based on the meeting date of May 1, 2026. Please confirm if this is correct.

The model didn't just extract — it resolved ambiguity and surfaced its assumption. That's useful.

What I'd tell someone starting this today

Trap	What to do
Browser back button	Deletes unsaved flows. Save constantly.
HTTP connector confusion	Use the green built-in HTTP, not the white Office 365 one
Flow not appearing in Copilot Studio	Build from Agent flows inside Copilot Studio, not from Power Automate
triggerBody() reference	In agent flows: `triggerBody()['text']`
inputs format	Array of `{id, data}` objects, not a plain string
Model name	Use `anthropic/claude-sonnet-4-6`, not `gpt-4o`
example_output	Required. Don't skip it.
Result field	`results`, not `output`

Time and honest assessment

Total setup time: ~3 hours (across both parts)

An engineer would probably finish this in 30 minutes. For a non-engineer, 3 hours. Most of the errors were preventable by reading the API documentation first — which I didn't do carefully enough.

What worked well once running:

Natural language input → structured JSON output
Ambiguity resolution with explicit flagging
Claude Sonnet 4.6 as the processing model (Kawamura International uses Claude Team, so Microsoft picked it up automatically — mildly amusing)

What still needs work:

The polling loop adds latency. For a single record, StructFlow returns fast — but the Do until loop with 5-second delays adds overhead.
Error handling is minimal. If the API call fails mid-loop, the flow times out silently.

What's next

MCP connection. Same use case, different integration method. The comparison between REST API and MCP — setup effort, reliability, latency — is the next article.

Kawamura International is a translation and localization company documenting its AI process experiments in public. StructFlow, RefineLoop, RenderOCR — and whatever comes next.

A non-engineer CEO tried to connect Copilot Studio to LDX hub. Here's what happened.

Kozo-KI — Thu, 07 May 2026 00:42:49 +0000

I'm the CEO of a translation company. I'm not an engineer. I can read code, but I can't write it.

That's the context for everything that follows.

LDX hub recently launched plugins for n8n, Dify, and Copilot Studio, making it possible to call StructFlow — their structured data extraction API — from no-code workflow tools. I decided to try it myself instead of delegating.

Spoiler: it's not working yet. But I'm publishing this anyway, because a record of where things broke is more useful than a "it all went smoothly" writeup.

What I was trying to build

Goal: An agent in Copilot Studio that takes meeting minutes as input and returns structured action items.

Stack:

Microsoft Copilot Studio (agent)
Power Automate (flow / middleware)
LDX hub StructFlow (REST API)

Approach: REST API first. If that works, compare with MCP.

The architecture

User (Copilot Studio chat)
    ↓  pastes meeting minutes
Power Automate flow
    ↓  POST to StructFlow API
LDX hub StructFlow
    ↓  returns structured JSON
Power Automate flow
    ↓  passes result back
User (receives action items)

Straightforward on paper. Less so in practice.

Building the Power Automate flow

Finding the right trigger

Opened make.powerautomate.com, selected "Instant cloud flow."

First blocker: "Power Virtual Agents" trigger wasn't visible.

There was no search box on the trigger selection screen. I scrolled through the list and eventually found it. The label was slightly different from what the documentation described. Found it, selected it, moved on.

Input variable

Added a text input variable called minutes_text to the trigger. No issues here.

HTTP action

Added "Send an HTTP request" and configured:

URI: https://your-ldxhub-host.d2.zuplo.dev/structflow/jobs
Method: POST
Header: Authorization: Bearer {API_KEY}

Second blocker: the header field format.

Instead of separate "key" and "value" fields, this action uses a single text field per header, formatted as HeaderName: HeaderValue. So the Authorization header goes in as:

Authorization: Bearer your-api-key-here

Not obvious if you're used to other HTTP tools.

Polling loop

StructFlow is asynchronous. You POST a job, get back a job_id, and need to poll until status: "completed" before you can retrieve results.

In Power Automate, this means a Do until loop. The structure:

Initialize variable job_id (string)
Set variable — extract job_id from HTTP response
Delay 5 seconds
Initialize variable job_status (string)
Do until loop:
- GET request to check job status
- Set job_status from response
- Stop condition: job_status equals completed
Return result to Copilot Studio

Third blocker: the browser back button deletes your flow.

I hit the back button before saving. The flow was gone. Started over.

Lesson: save constantly in Power Automate. There's no autosave equivalent to what you'd expect from a modern web app.

The Do until condition also caused an error when I tried to reference job_status via the GUI. Fixed it by switching to "Edit in advanced mode" and typing the expression directly:

@equals(job_status, 'completed')

The flow eventually completed. Green banner: "Your flow is ready to run."

Connecting to Copilot Studio

Created an agent called "Minutes Assistant" in Copilot Studio.

Observation: the default model was Claude Sonnet 4.6.

Our company uses Claude Team, so Microsoft apparently picked it up automatically. Our enterprise agent running on Claude — mildly amusing given the context of this article.

Now for the main blocker: the Power Automate flow didn't appear in Copilot Studio's tool list.

Same environment, same account. The flow just wasn't visible. I tried searching, browsing the Workflow tab — nothing.

Explored the sidebar and found "Flows" → "Agent flows" — a feature where you describe what you want in natural language and AI generates a flow. The AI generated something instantly, but the action it created pointed to an unrecognizable internal ID — certainly not the StructFlow API in any recognizable form.

Where things stand

Step	Status
Power Automate flow	✅ Built
Do until polling loop	✅ Working
Copilot Studio connection	❌ Unresolved
Agent flow AI generation	⚠️ Generated, not verified

What tripped me up:

No autosave — browser back = flow gone
Single-field header format — Key: Value in one box, not two
Flow not visible in Copilot Studio — same environment, still not showing
AI-generated flow — unclear what API it's actually calling

What's next

Inspect the AI-generated agent flow to see what it's actually calling
Test whether StructFlow is being invoked correctly
If it works: run it against real meeting minutes
Part 2 will cover the full resolution (and MCP comparison)

I'll publish the follow-up when it actually works. This one ends here — unresolved, on purpose.

Kawamura International is a translation and localization company. We're documenting our AI process experiments as we go — StructFlow, RefineLoop, RenderOCR, and whatever comes next.

"The CEO Wrote This with MCP" — How I Used an AI Agent to Examine the Translation Industry's Pain Points

Kozo-KI — Fri, 01 May 2026 04:17:30 +0000

Kawamura International / LDX Lab

Starting with the Pain Points

There are some quietly troublesome problems in the translation field.

When IR or legal documents are run through a general-purpose MT system, number formatting falls apart. Honorific language does not match the writing style. Company-specific terminology gets replaced with different translations. The feeling of "Having to fix this again?" can end up accounting for most of the post-translation work.

This is less a problem with translation tools than a limitation of processing unstructured text without context. The same thing happens with meeting minutes. Who is supposed to do what by when is buried in the text, and you cannot tell unless you read it.

What I set out to do today was test what would happen if that process were handed over to an AI agent.

My Background

Let me be honest from the start. I am not an engineer.

We have a CTO. We also have people who can read code. But I conducted today's test entirely on my own. What I used was the Claude.ai chat interface and our in-house API (LDX hub), connected via MCP. I did not write a single line of code.

This also serves as a record of where non-engineers get stuck when using AI agents.

Architecture: Connecting APIs with MCP

The setup is simple.

Claude (chat)
  └── Zuplo MCP (API gateway)
        └── LDX hub
              ├── StructFlow   ← Turns unstructured text into structured JSON
              ├── RefineLoop   ← Post-translation terminology and quality refinement
              └── RenderOCR    ← Text extraction from PDFs and images

LDX hub is an API service developed in-house. It handles translation, OCR, and data structuring. It runs on an API gateway called Zuplo, and Zuplo has MCP server functionality.

In other words, if you connect Zuplo MCP to Claude, Claude itself will decide when to call the API.

Getting It Connected (Where I Got Stuck)

The connection process has three steps.

Generate an API key in the Zuplo dashboard
Add the MCP server in Claude.ai settings (URL + API key)
Verify the connection

It looked simple, but I got stuck at step 1.

It wasn't immediately obvious where in the Zuplo dashboard to generate the key. I ended up reading through the documentation to find it. Later, while doing the VOC analysis (described below), I came across a user review that described exactly the same experience:

"Honestly struggled with the initial setup.
 Figuring out that API keys are issued from the Zuplo
 dashboard wasn't obvious. But once it was running,
 StructFlow's accuracy was satisfying."

This was one of the fictional review data items I processed with StructFlow today, but it felt very real. I'll make a tutorial video.

Verification 1: Extracting Action Items from Meeting Minutes

The first thing I tried once connected was structuring meeting minutes.

I simply described what I wanted: "Please extract the person responsible, the task, and the deadline from five sets of meeting minutes."

Claude assembled the job on its own.

{
  "model": "anthropic/claude-sonnet-4-6",
  "system_prompt": "Extract all action items from the meeting minutes...",
  "example_output": {
    "action_items": [
      { "assignee": "Tanaka", "task": "Fix the bug", "due_date": "2026-05-02" }
    ]
  },
  "inputs": [
    { "id": "minutes-001", "data": { "text": "..." } }
    // All 5 submitted at once
  ]
}

I did not write any of this JSON. Claude selected the createStructFlowJob tool on its own and called it.

Result: 13 action items extracted from 5 sets of minutes in 11 seconds. 100% success rate.

What I found interesting: from the sentence "Tanaka will fix this by April 22. (Note: confirmed as already resolved as of today)," it separately extracted the deadline and the completion flag. It is reading context, not simply extracting keywords.

Verification 2: VOC Analysis of 100 Reviews

Next, I tried a VOC (Voice of Customer) analysis of app reviews.

When I said "I want to analyze 100 mixed Japanese-English reviews for a task management app tentatively called Flowra," Claude:

Generated the 100 review data items itself (70 in Japanese, 30 in English)
Submitted 2 parallel jobs to StructFlow
Once the results came back, formatted them into an HTML report

All I did was describe what I wanted in three sentences.

The five fields it extracted per review:

Each review → StructFlow → Structured JSON
               ├─ sentiment (positive / negative / neutral)
               ├─ nps_score (integer 0–10)
               ├─ evaluation_axes (axis / score / comment)
               ├─ mentioned_features (feature names mentioned)
               └─ improvement_requests (requested improvements)

Result: All 100 items completed successfully. Processing time was 69 seconds for Job 1 and 59 seconds for Job 2. Output character count was 4.3× the input (33,791 characters).

The 4.3× figure is because comments are automatically generated for each evaluation axis, not simply classified. Something like "Ease of use: Task management has genuinely become easier (positive)" is generated for 100 items across multiple axes.

When I aggregated the data, a polarization emerged: 37% were promoters (NPS 9–10), and 37% were also detractors (0–6). It is a typical product pattern where dissatisfaction with pricing coexists with enthusiasm for features.

What I Noticed: What "Understanding Intent" Actually Means

The key thing I realized from spending the day on this: once MCP gives Claude access to tools, Claude decides on its own how to call them.

I had not read the StructFlow API reference. I had no idea how to submit jobs. But it called createStructFlowJob, polled with getStructFlowJob, and moved on once the job was done.

This is different from code completion. It is decomposing a task and executing autonomously within the constraints of the tools.

However, there is a prerequisite. The tool schema must be accurately defined. Because Zuplo exposes parameters accurately, Claude can pass the correct arguments. If the schema is ambiguous, things stop before "understanding intent" even becomes relevant.

Honest Assessment

What worked:

Once I described what I wanted, Claude handled job assembly, submission, polling, and formatting
Quality did not drop even with mixed Japanese-English text
Even as a non-engineer, once connected, I was able to produce something that actually works

What did not work / areas for improvement:

Initial setup takes real effort. The API key location in particular was not obvious
I ended up pasting an API key into the chat, which was a security issue (I reissued it immediately)
Direct calls to the Anthropic API from the browser were blocked by CORS (I worked around it a different way)

I am including the failures here. A record of where things broke is more reproducible than a "everything went perfectly" account.

Today's Summary

Verification	Volume	Processing Time	Success Rate
Meeting minutes → Action items	5 items	11 seconds	100%
Reviews → VOC structuring	100 items	69s + 59s	100%

In both cases, all I did was describe what I wanted.

What's Next

"Isn't plain LLM enough?" — put to the test: Comparing the same 100 minutes submitted directly to the Anthropic API (Part 2)

MCP takes a bit of effort to get connected. But once it's connected, Claude takes over. All you need to do is tell it what you want. That holds true even for non-engineers.

LDX Lab case studies: https://ldxlab.io/ldxhub/case
StructFlow / RefineLoop / RenderOCR / TermWeave (coming soon)