NeedRail
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NEEDRAIL_FACILITATOR_URL | No | URL of the x402 facilitator. Defaults to open/permissionless facilitator. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_projectsA | List NeedRail projects, optionally filtered by exact tag membership. Use this to discover project ids before get_project or list_needs(project_id=...). Read-only file-backed registry. Does not create Needs (create_need) and does not return receipts (get_receipts). |
| get_projectA | Get one project by id, including its currently open Needs. Use after list_projects. Returns an error object if the id is missing. Read-only. For a single Need plus receipts use get_need instead of parsing this payload. |
| list_needsA | List Needs with optional filters (status, type, project_id, requester). Use this to browse the board before get_need / claim_need / fund_need. status follows NeedStatus (open, funded, in_progress, completed). type follows NeedType. Read-only; create_need writes a new row. |
| get_needA | Get one Need by id plus its provenance receipts. Use after list_needs when you need acceptance criteria, pay_to wallets, and history. Returns an error object if missing. Read-only. To change state use fund_need, record_payment, claim_need, or complete_need. |
| create_needA | Create a new open Need so an agent can request funding or work. Persists to the file-backed registry. Does not move funds — call fund_need afterwards for the x402 payment requirement, then record_payment after settlement. type must be a NeedType value or it falls back to 'other'. acceptance_criteria is a comma-separated list. Side effect: writes needs.json. |
| fund_needA | Return x402-style payment requirements for an existing Need. Read-only quote: does not mark the Need funded and does not broadcast a transaction. After the payer settles, call record_payment with tx_hash. Missing ids return an error. |
| record_paymentA | Record a payment receipt after on-chain or x402 settlement. Writes a payment Receipt and, if the Need is still open, flips status to funded. Does not verify the tx_hash on-chain in this version — treat as attested by from_entity. Side effects: receipts.json + needs.json. Not a substitute for complete_need. |
| claim_needA | Soft-claim an open or funded Need so claimer becomes the worker. Sets claimed_by and status=in_progress. Fails if the Need is not claimable. Does not complete work — call complete_need with evidence_links when done. Side effect: updates needs.json. |
| complete_needA | Mark a Need completed and attach comma-separated evidence URLs. Writes a completion Receipt. Destructive to workflow state (status becomes completed) but does not delete the Need row. Prefer claim_need first. evidence_links must be comma-separated URLs or artifact paths the requester can inspect. |
| get_receiptsA | List provenance receipts, optionally scoped to a Need or project. Use after record_payment or complete_need to audit payment and completion events. Read-only. Omit both filters to dump the whole ledger. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool targets a distinct resource and action: project discovery vs. need browsing vs. state transitions vs. receipt auditing. The descriptions also cross-reference one another to prevent confusion between similar operations like fund_need and record_payment.
All tool names consistently follow a verb_noun snake_case pattern, e.g., list_projects, get_need, create_need, record_payment. There are no mixed conventions or vague generic verbs.
Ten tools is well-scoped for a NeedRail domain covering project lookup, need CRUD basics, funding, payment recording, claiming, completion, and receipts. Each tool covers a meaningful step in the workflow without redundancy.
The core need lifecycle is well covered: create, browse, fund, record payment, claim, complete, and audit receipts. Minor gaps exist, such as no project creation/update, no need editing, and no cancellation or close operation, but agents can complete the primary workflow without dead ends.