# Flowgraf

> Create and edit architecture diagrams from your AI agent; get an SVG and a live editable canvas.

- name: in.flowgraf/flowgraf
- version: 0.1.2
- connection class: unknown (unknown)
- trust: 43/100 flags: no-repository
- quality: 74/100 (needs work)
- owner: not claimed
- descriptor: https://api.protogrid.dev/v1/servers/in.flowgraf%2Fflowgraf
- tools: https://api.protogrid.dev/v1/servers/in.flowgraf%2Fflowgraf/tools

**Not classified yet.** The remote endpoints have not been probed successfully, or the listing has nothing to connect to.

## Connection (mcpServers)

```json
{
  "mcpServers": {
    "flowgraf": {
      "type": "http",
      "url": "https://flowgraf.in/api/mcp"
    }
  }
}
```


## Trust

- hygiene: 80
- liveness: 0
- freshness: 65
- provenance: 45
- drivers: +dns-namespace -unreachable(10 failures) ~updated-103d-ago -no-repository
- Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed.

## Quality 74/100 (needs work)

### protocol: 75 (weight 25)

- warn `protocol.modern`: newest supported version is 2025-11-25; 2026-07-28 not supported, older versions are deprecated until 2027-07-28
- n/a `protocol.stateless`: only applies to 2026-07-28 servers
- pass `protocol.transport`: streamable HTTP
- n/a `protocol.list_ttl`: only applies to 2026-07-28 servers

### authorization: n/a (weight 15)

- n/a `auth.prm`, `auth.as_metadata`, `auth.cimd`: no remote uses OAuth
- n/a `auth.secret_in_url`: no templated URL

### tool hygiene: 64 (weight 30)

- pass `tools.descriptions`: every tool has a description
- warn `tools.description_length`: 2 tools have descriptions over 1,024 characters, which crowds the context
- pass `tools.schemas`: every tool has an object input schema
- fail `tools.annotations`: no tool declares readOnlyHint or destructiveHint, so clients cannot tell safe calls from risky ones
- fail `tools.directory_hints`: no tool declares all four of readOnlyHint, destructiveHint, idempotentHint and openWorldHint; missing: create_diagram (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); edit_diagram (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); get_diagram (readOnlyHint, destructiveHint, idempotentHint, openWorldHint)
- pass `tools.token_cost`: about 4,145 tokens to load every tool
- pass `tools.api_dump`: tools are not a one-to-one API dump

### stability: 100 (weight 15)

- pass `stability.changes`: no tool changes in 30 days
- pass `stability.rug_pull`: no tool changed its meaning under the same name

### dependencies: 67 (weight 15)

- pass `deps.known_vulns`: no known advisory in 98 resolved packages
- fail `deps.mcp_sdk_version`: @modelcontextprotocol/sdk 1.26.0 has 1 known advisory (GHSA-6qxp-vccf-f47h); update @modelcontextprotocol/sdk to 1.31.0 or later
- pass `deps.resolvable`: flowgraf-mcp@0.1.2 resolved: 98 packages

- tools: 3, about 4,145 tokens to load them all
- tool set hash: e54afe592b52ee042299a8c5365cd42d
- badge: [![protogrid quality](https://protogrid.dev/badge/in.flowgraf/flowgraf.svg)](https://protogrid.dev/servers/in.flowgraf/flowgraf)
- Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed.

### Tool changes

_No tool definition changes recorded._

## Dependencies

- npm flowgraf-mcp@0.1.2: resolved, 97 dependencies, MCP SDK @modelcontextprotocol/sdk 1.26.0
  - GHSA-6qxp-vccf-f47h (high) in `` @modelcontextprotocol/sdk@1.26.0 ``, direct, fixed in `` 1.31.0 ``, advisory summary: "MCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP server" https://osv.dev/vulnerability/GHSA-6qxp-vccf-f47h

Dependency graphs from deps.dev; advisories from OSV.dev, including the GitHub Advisory Database and the PyPI Advisory Database; all CC BY 4.0.

## Remotes

- https://flowgraf.in/api/mcp (streamable-http, auth none, reachable false, uptime30d 0.75609756)

## Packages

- npm flowgraf-mcp@0.1.2

## Tools (3)

- `create_diagram`: Create a NEW architecture diagram from a graph that YOU author, and get back a shareable, editable canvas URL plus a rendered SVG and Mermaid.

You produce only the SEMANTICS — nodes, the groups (VPC/cluster/...) they live in, and the directed edges between them. You do NOT lay anything out: never send x/y/position/pinned. A deterministic layout engine computes all geometry and an icon layer picks the pictures from each node's kind.

kind.catalog is one of aws | gcp | azure | k8s | saas | generic, each with rich per-catalog kind.types (e.g. aws:lambda, gcp:bigquery, azure:cosmos_db, k8s:deployment, saas:kafka):
- "aws" (api_gateway, lambda, s3, rds, dynamodb, sqs, bedrock, kinesis, fargate, eventbridge, aurora, ...).
- "gcp" (compute_engine, gke, cloud_run, cloud_sql, spanner, firestore, bigquery, pubsub, dataflow, vertex_ai, ...).
- "azure" (virtual_machine, aks, app_service, functions, blob_storage, sql_database, cosmos_db, service_bus, event_hubs, key_vault, ...).
- "k8s" (pod, deployment, statefulset, daemonset, job, cronjob, service, ingress, configmap, secret, hpa, ...).
- "saas" for hosted third-parties (redis, postgresql, mysql, mongodb, kafka, stripe, twilio, auth0, github, cloudflare, ...).
- "generic" primitive when nothing branded fits: service, database, cache, queue, user, external_system, storage, gateway, function, note.
- "generic" FLOWCHART kinds for processes/flowcharts: process, decision, terminator, data, document, subprocess.
edge.kind is one of: request, response, async_event, data_flow, dependency, network, generic.

WORKED EXAMPLE — a user hitting an API in a VPC that talks to Postgres:
{
  "title": "Web API",
  "domain": "cloud_architecture",
  "graph": {
    "groups": [{ "id": "g_vpc", "label": "VPC", "type": "vpc" }],
    "nodes": [
      { "id": "n_user", "label": "User", "kind": { "catalog": "generic", "type": "user" } },
      { "id": "n_api", "label": "API", "kind": { "catalog": "aws", "type": "api_gateway" }, "parentId": "g_vpc" },
      { "id": "n_db", "label": "Postgres", "kind": { "catalog": "aws", "type": "rds" }, "parentId": "g_vpc" }
    ],
    "edges": [
      { "id": "e1", "source": "n_user", "target": "n_api", "kind": "request" },
      { "id": "e2", "source": "n_api", "target": "n_db", "kind": "data_flow" }
    ]
  }
}

Returns { diagramId, url, svg, mermaid, version }. Give the user the url — opening it shows the same diagram on an editable canvas (anonymous; it's theirs to claim by signing in). To change the diagram afterwards, use get_diagram then edit_diagram.
- `edit_diagram`: Apply a list of operations to an EXISTING diagram. The ops re-use this tool's op vocabulary; you author them, we validate + apply + re-layout + re-render.

ALWAYS call get_diagram(diagramId) first: it returns the current ids and the `version`. Pass that version as `baseVersion`. If the diagram changed since you fetched it, you get a STALE_VERSION error telling you the current version — refetch with get_diagram, recompute your ops, and retry.

The operations (each element of `ops`):
- add_node    { op, node:{ id, label, kind, parentId? } }
- remove_node { op, id }                       (also drops edges touching the node)
- update_node { op, id, patch:{ label?, kind?, parentId?, metadata? } }
- add_edge    { op, edge:{ id, source, target, kind, label?, directed? } }
- remove_edge { op, id }
- update_edge { op, id, patch:{ source?, target?, label?, kind?, directed? } }
- add_group   { op, group:{ id, label, type, parentId? } }
- remove_group{ op, id }
- move_to_group { op, nodeId, groupId }        (groupId null un-nests the node)
- set_layout  { op, patch:{ direction?, spacing? } }
- insert_between { op, newNode:{ id, label, kind, parentId? }, sourceId, targetId, inKind?, outKind? }

insert_between IS THE KEY OP for "add X between A and B" requests. It splices newNode onto the existing A→B edge: removes that edge, adds the node, and wires A→newNode→B so the connection re-routes through it automatically.

WORKED EXAMPLE — "add a Redis cache between the API and the DB" on the diagram above:
1) get_diagram(diagramId) → shows nodes n_api, n_db and version 1.
2) edit_diagram({ diagramId, baseVersion: 1, ops: [
     { "op": "insert_between", "sourceId": "n_api", "targetId": "n_db",
       "newNode": { "id": "n_redis", "label": "Redis", "kind": { "catalog": "saas", "type": "redis" }, "parentId": "g_vpc" },
       "inKind": "request", "outKind": "data_flow" }
   ] })
The API→DB edge is gone and now flows API→Redis→DB. Never send x/y/position — geometry is computed for you.

Node kinds: catalog ∈ {aws, gcp, azure, k8s, saas, generic} with rich per-catalog types (e.g. aws:lambda, gcp:bigquery, azure:cosmos_db, k8s:deployment, saas:kafka), plus generic flowchart kinds (process, decision, terminator, data, document, subprocess).

Returns { url, svg, mermaid, appliedOps, version }.
- `get_diagram`: Fetch a diagram's raw IR (nodes, groups, edges with their real ids) and its current `version`. Call this before edit_diagram so your ops reference ids that actually exist and you pass the correct baseVersion. Returns { diagram, version }.