Openterms-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENTERMS_API_KEY | No | ||
| OPENTERMS_API_URL | Yes | https://openterms.com |
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": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| issue_receiptA | Issue a cryptographically signed terms receipt BEFORE your agent takes an action. Returns an Ed25519-signed receipt proving consent to terms. If this returns POLICY_DENIED or POLICY_ESCALATION_REQUIRED, STOP and notify the user. |
| verify_receiptB | Verify a receipt's cryptographic integrity. Public — no API key needed. |
| check_balanceA | Check workspace USDC balance (minor units, 1 USDC = 1,000,000). |
| get_pricingA | Get current per-receipt pricing. Public — no API key needed. |
| list_receiptsC | List recent receipts for this workspace. |
| get_policyA | Get the active policy (guardrails) for this workspace. Returns the rules that govern what this agent is allowed to do. An agent SHOULD call this on startup to understand its constraints. |
| simulate_policyA | Test whether a hypothetical action would be allowed by the current policy WITHOUT actually issuing a receipt. Use this to pre-check before acting. |
| policy_decisionsA | View recent policy evaluation decisions (allow/deny/escalate) for this workspace. Useful for auditing and understanding what the policy engine has been doing. |
| verify_receipt_by_hashA | Verify a receipt by its canonical hash. Public — no API key needed. Use this to check if an agent has a valid consent receipt before serving a request. Returns receipt details and cryptographic verification result. |
| provider_activityA | View receipt activity against your terms URL (requires provider API key via OPENTERMS_PROVIDER_KEY). Shows stats, unique agents, and recent receipts for your API. |
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
Most tools have clearly distinct purposes: issuing, verifying, listing, policy simulation, and provider stats are separate concerns. The only ambiguity is between verify_receipt and verify_receipt_by_hash, though their descriptions clarify the different input methods.
Most tool names follow a consistent lowercase verb_noun pattern such as verify_receipt, issue_receipt, and get_policy. Two noun-phrase names, policy_decisions and provider_activity, deviate slightly but are still readable and predictable.
With 10 tools, the server is well-scoped for its terms/receipt policy domain. Each tool serves a distinct operational need: policy access, simulation, decisions, receipt issuance/verification, and workspace/provider management.
The tool set covers policy retrieval/simulation, receipt issuance/verification/listin, and workspace/provider accounting, so the core workflow is complete. Minor gaps exist such as no explicit receipt revocation or policy update, but these are not clearly required by the domain.