procurement-graph
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@procurement-graph show me the build order for category strategy"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
procurement-graph
A dependency graph of strategic sourcing artifacts and analyses, exposed as an MCP server.
This is an open specification I publish through Canonical Agency. It generalizes patterns from procurement and spend-intelligence engagements at two enterprises under NDA.
What it models
The strategic sourcing process is usually drawn as a linear set of phases. I find that framing brittle. Phases describe when work happens; they do not describe what depends on what. The same spend cube feeds the diagnostic, the category strategy, and the ongoing performance dashboard. The same supplier scorecard depends on baseline metrics captured during onboarding. Treating these as a graph (nodes plus edges) makes it possible to ask the questions that actually matter on an engagement:
What deliverables are blocked by missing inputs?
If raw spend changes, what gets invalidated?
Given my entity-profile data, which analyses can I run today?
What is the build order to produce a category strategy?
Phases (0 through 6) remain in the spec as a navigational frame. They are not the structural spine.
Related MCP server: aspark-graph
Phase model
Seven phases, zero through six, anchoring the program from opening diagnostic through ongoing performance management.
Phase 0 Opportunity Assessment & Business Case
Phase 1 Spend Analysis & Category Segmentation
Phase 2 Supply Market Research
Phase 3 Strategy Development
Phase 4 Sourcing Execution (RFx + Negotiation)
Phase 5 Implementation & Supplier Transition
Phase 6 Performance Management & Benefits TrackingLayer model
Every node lives in one of five layers. Layers describe what kind of work a node is, independent of which phase it belongs to.
Layer 1 Truth and facts (raw data, supplier master, contracts)
Layer 2 Analytical assets (spend cube, should-cost, risk scores)
Layer 3 Decision artifacts (category strategy, negotiation strategy)
Layer 4 Execution artifacts (RFx packages, contracts, transition plans)
Layer 5 Proof and control (benefits tracking, scorecards, compliance)Tools (v0.4)
Navigation and catalog:
Tool | Purpose |
| Seven phases with one-line purpose |
| Full phase spec (purpose, included activities, layer focus) |
| Layer 2 analyses, filterable by feasibility with PO-line data |
| Full analysis spec (firms, inputs, method, outputs, watch-outs) |
| Layer 3-5 deliverables |
| Full deliverable spec (purpose, audience, components, dependencies) |
| Cross-phase artifacts (governance, RAID, benefits tracker) |
| Shared fictional engagement (TechnoFlex PSA resin) that anchors all examples |
| Filled-in artifact examples, each tied to a parent node slug |
| Fetch a filled-in TechnoFlex example for a given parent node slug |
Graph traversal:
Tool | Purpose |
| Direct upstream nodes for a given node |
| Direct downstream nodes for a given node |
| Transitive closure of downstream nodes (impact analysis) |
| Topological sort of every upstream node plus the target |
| Nodes flagged HIGH feasibility against PO-line + entity-profile data |
| Nodes blocked by MISSING inputs, ranked by transitive impact |
Install (local / editable)
cd /Users/fbaig/Projects/procurement-graph
uv sync
uv run procurement-graphValidate the content corpus
procurement-graph validate runs the integrity checks the test suite enforces (edge consistency, acyclicity, example linkage, phase continuity) as a standalone CLI. Useful for content editors to verify their work before committing.
uv run procurement-graph validateClaude Desktop config
{
"mcpServers": {
"procurement-graph": {
"command": "uv",
"args": [
"--directory",
"/Users/fbaig/Projects/procurement-graph",
"run",
"procurement-graph"
]
}
}
}Repository layout
content/
├── phases/ seven phase descriptions
├── analyses/ Layer 2 analyses from the procurement analytics catalog
├── deliverables/ Layer 3-5 deliverables from the phase-by-phase taxonomy
├── horizontal/ cross-phase artifacts (governance, RAID, benefits tracker)
├── engagement/ shared fictional engagement (TechnoFlex PSA resin)
└── examples/ 15 filled-in artifact examples anchored to the TechnoFlex engagement
src/procurement_graph/
├── __main__.py entrypoint dispatching to MCP server or validate CLI
├── server.py FastMCP app and tool registrations (16 tools)
├── loaders.py cached file readers
├── parsing.py YAML frontmatter and markdown body parsing
├── models.py pydantic node, phase, and example models
├── graph.py dependency-graph traversal (BFS, topo sort, feasibility)
└── validate.py standalone content-integrity checksThe methodology content lives in content/ as markdown with YAML frontmatter, so the source of truth is editable without touching the server code.
License
Apache-2.0.
Available Tools
16 toolsbuild_orderA
Topological sort of every upstream node plus the target. Answers 'in what order should I build the inputs to produce this artifact?'.
Useful for engagement planning: given a target deliverable (e.g., category-strategy), return the dependency chain so the team builds prerequisites before dependents.
Inputs: target_slug (required). Returns: object
data_gap_analysisA
Group nodes by the missing input that blocks them, ranked by impact.
Each entry names the missing data source (e.g., 'Contract metadata') and lists the nodes it directly blocks plus the transitive downstream impact. Used to prioritize data acquisition: investing in the input at the top of the list unlocks the largest share of the graph.
Inputs: no named parameters. Returns: object
feasible_nowA
Nodes whose declared inputs are all HAVE for a PO-line + entity-profile data set. Answers 'what analyses can I run today without acquiring new data?'.
The differentiated filter behind this whole spec. Most procurement libraries can list the analyses; this one tells you which ones are runnable against your data.
Inputs: no named parameters. Returns: object
get_analysisB
Full spec for a single analysis: source firms, inputs and their feasibility, method, primary outputs, decision enabled, watch-outs, and graph dependencies.
Inputs: slug (required). Returns: object
get_artifact_exampleA
Fetch a filled-in example for a given parent node slug.
Returns the example artifact (as it would land on a stakeholder's desk), populated with concrete numbers, supplier names, and findings from the shared engagement. Useful as a few-shot reference for what a strong version of the artifact looks like in practice.
Inputs: slug (required). Returns: object
get_deliverableB
Full spec for a single deliverable: purpose, audience, inputs, components, output format, quality markers, and graph dependencies.
Inputs: slug (required). Returns: object
get_dependenciesA
Direct upstream nodes for a given node. Answers 'what does this need?'.
Returns the immediate predecessors only. For full upstream closure, use build_order(slug), which returns every transitive ancestor in dependency order.
Inputs: slug (required). Returns: object
get_dependentsA
Direct downstream nodes for a given node. Answers 'what uses this?'.
Returns the immediate successors only. For full downstream impact, use what_breaks_if(slug), which returns every transitively-affected node.
Inputs: slug (required). Returns: object
get_engagement_contextA
The shared fictional engagement narrative that anchors every example. Read this first to see how examples thread together coherently.
Inputs: no named parameters. Returns: object
get_phaseA
Full spec for a single phase: purpose, included activities, source firms, and the layer focus of work performed in this phase.
Inputs: number (required). Returns: object
list_analysesA
List analyses from the procurement analytics catalog (Layer 2 nodes).
Filter by primary_phase (0-6), layer (1-5), or feasibility with PO-line data ('HIGH', 'MEDIUM', 'LOW'). Feasibility is the most useful filter: it tells you which analyses can be run today with PO-line + entity-profile data alone.
Inputs: primary_phase, layer, feasibility. Returns: Generic wrapper for non-object return types.
list_artifact_examplesA
List filled-in artifact examples anchored to the shared engagement context.
Each example's slug matches a parent node slug, so a category-strategy example
is at content/examples/category-strategy.md and threads with the spend-cube,
rfx-package, and other examples through the TechnoFlex PSA resin narrative.
Use get_engagement_context() for the shared engagement first, then
get_artifact_example(slug) to fetch a specific filled-in artifact.
Inputs: no named parameters. Returns: Generic wrapper for non-object return types.
list_deliverablesC
List deliverables from the phase-by-phase taxonomy (Layer 3-5 nodes).
Deliverables are the formatted artifacts handed to stakeholders: strategy docs, RFx packages, contracts, scorecards. Each names which upstream analyses and deliverables it depends on.
Inputs: primary_phase, layer. Returns: Generic wrapper for non-object return types.
list_horizontal_artifactsA
List horizontal artifacts that span multiple phases: governance model, RAID log, benefits tracker, knowledge repository.
Inputs: no named parameters. Returns: Generic wrapper for non-object return types.
list_phasesA
List the seven phases of the strategic sourcing process (Phase 0 through 6).
Phases are a navigational frame, not the structural spine. The spine is the dependency graph of nodes (analyses, deliverables, horizontal artifacts).
Inputs: no named parameters. Returns: Generic wrapper for non-object return types.
what_breaks_ifB
Transitive closure of downstream nodes. Every node that would become stale if this one changed materially (new data, redefined taxonomy, restated baseline).
Useful for impact analysis: 'if I restate the spend cube, what reviews do I need to redo?'
Inputs: slug (required). Returns: object
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 16 tools
Each tool targets a distinct concept or action: ordering, feasibility, analysis details, artifact examples, deliverables, dependencies, etc. The descriptions clearly differentiate them, and there is no overlap in purpose.
All tool names follow a consistent snake_case verb_noun pattern (e.g., build_order, list_analyses, get_dependencies). The exceptions like feasible_now and data_gap_analysis still align with adjective_noun, maintaining overall consistency.
The 16 tools cover the full range of operations expected for a procurement knowledge graph: listing, getting details, dependency analysis, feasibility checks, and phase browsing. Neither too few nor too many for the domain.
The tool surface provides comprehensive coverage for a read-only catalog: listing all node types, fetching full specs, exploring dependencies both upstream and downstream, ordering builds, and assessing feasibility. No obvious gaps for the stated purpose.
Maintenance
Related MCP Connectors
MCP access to the U.S. federal procurement graph: contracts, opportunities, entities, and more.
Repository knowledge graph MCP server for codebase understanding and debugging.
Siftable MCP server for governed work, knowledge, calendar, people, datasets, and Vault.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Related MCP Servers
- AlicenseAqualityCmaintenanceExposes a materialized service dependency graph as an MCP toolset for persistent, queryable root-cause analysis via Cypher queries.51Apache 2.0
- AlicenseBqualityBmaintenanceA lean, local knowledge graph that joins a repo's code to its aSPARK delivery artifacts, enabling agents to trace user stories to code and assess impact of changes, served over MCP.93MIT
- FlicenseNot gradedqualityDmaintenanceEnables querying cross-repo code dependencies, HTTP routes, database tables, and queues via an MCP server using Cypher queries.-
- AlicenseNot gradedqualityDmaintenanceExposes code graphs across multi-program repositories via MCP, enabling humans and agents to query the fleet with evidence.MIT