Problem
FlowMCP v2.0.0 is designed for REST/JSON APIs, which covers ~70% of the APIs researched. However, many valuable data sources use non-REST protocols that could still be wrapped as FlowMCP schemas with appropriate handler patterns.
Non-REST Protocols Encountered
From researching 300+ APIs for FlowMCP schema issues:
| Protocol |
APIs |
Handler Complexity |
| SDMX (Statistical Data) |
ECB, Eurostat, IMF, BIS, Bundesbank, OECD |
Medium — URL path encoding, XML→JSON transform |
| WFS/OGC (Geospatial) |
Copernicus, EEA Waterbase, national geo services |
Medium — XML/GML response parsing |
| SPARQL (Semantic Web) |
Wikidata, EU Open Data, DBpedia, UNESCO |
High — query language in request body |
| TAP/ADQL (Astronomy) |
SIMBAD, VizieR, ESA archives |
High — SQL-like query language |
| GraphQL |
GitHub (some endpoints), Dune (new API) |
Medium — query in POST body |
| SOAP/XML |
Some government services, WSDL-based |
High — XML envelope construction |
Current Situation
The handler pipeline (preRequest → executeRequest → postRequest) is powerful enough to handle all of these, but schema authors have no guidance on:
- How to structure
preRequest for query language injection (SPARQL, ADQL)
- How to transform XML/GML responses in
postRequest
- Best practices for SDMX URL path construction
- When to use
executeRequest override vs standard fetch
Proposed Addition
Add a cookbook section to the spec with handler patterns for the most common non-REST protocols:
- SDMX Pattern — URL path encoding, XML→JSON, shared dimension lists
- GraphQL Pattern — POST body with query, variables extraction
- SPARQL Pattern — Query injection, result binding transformation
- XML/WFS Pattern — Response parsing, GeoJSON conversion
Each pattern should include a complete minimal example schema.
Priority
P3 — Unlocks ~30% more API coverage. Not blocking for production but significantly expands the FlowMCP ecosystem reach.
Problem
FlowMCP v2.0.0 is designed for REST/JSON APIs, which covers ~70% of the APIs researched. However, many valuable data sources use non-REST protocols that could still be wrapped as FlowMCP schemas with appropriate handler patterns.
Non-REST Protocols Encountered
From researching 300+ APIs for FlowMCP schema issues:
Current Situation
The handler pipeline (
preRequest→executeRequest→postRequest) is powerful enough to handle all of these, but schema authors have no guidance on:preRequestfor query language injection (SPARQL, ADQL)postRequestexecuteRequestoverride vs standard fetchProposed Addition
Add a cookbook section to the spec with handler patterns for the most common non-REST protocols:
Each pattern should include a complete minimal example schema.
Priority
P3 — Unlocks ~30% more API coverage. Not blocking for production but significantly expands the FlowMCP ecosystem reach.