procurement-graph
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Capabilities
Features and capabilities supported by this server
| Capability | Details |
|---|---|
| tasks | {
"list": {},
"cancel": {},
"requests": {
"tools": {
"call": {}
},
"prompts": {
"get": {}
},
"resources": {
"read": {}
}
}
} |
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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). |
| get_phaseA | Full spec for a single phase: purpose, included activities, source firms, and the layer focus of work performed in this phase. |
| 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. |
| get_analysisB | Full spec for a single analysis: source firms, inputs and their feasibility, method, primary outputs, decision enabled, watch-outs, and graph dependencies. |
| 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. |
| get_deliverableB | Full spec for a single deliverable: purpose, audience, inputs, components, output format, quality markers, and graph dependencies. |
| list_horizontal_artifactsA | List horizontal artifacts that span multiple phases: governance model, RAID log, benefits tracker, knowledge repository. |
| get_engagement_contextA | The shared fictional engagement narrative that anchors every example. Read this first to see how examples thread together coherently. |
| 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 Use |
| 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. |
| 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. |
| 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. |
| 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?' |
| build_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. |
| 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. |
| 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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/mfbaig35r/procurement-graph'
If you have feedback or need assistance with the MCP directory API, please join our Discord server