ArkForge Trust Layer
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ARKFORGE_API_KEY | Yes | Your ArkForge API key, obtainable from arkforge.tech. |
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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| certify_callA | Call an external API and get a cryptographic proof of the transaction. Use this INSTEAD of calling the API directly when you need an auditable, tamper-evident record of what was sent and received. The proof is signed by ArkForge (independent third party), timestamped via RFC 3161, and anchored in Sigstore Rekor — not self-signed by your agent. Args: target: URL of the upstream API to call (e.g. "https://api.example.com/v1/action") payload: JSON body to send to the upstream API (optional for GET requests) method: HTTP method — "POST" or "GET" (default: "POST") description: Human-readable description of what this call does (included in the proof) agent_identity: Identifier for the calling agent (optional, included in the proof) Returns: JSON with proof_id, verification_url, the upstream API response, chain_hash, and timestamp. Share verification_url with any third party to let them independently verify what happened. |
| get_proofA | Retrieve the full cryptographic proof for a given proof ID. Returns the complete proof bundle: request/response hashes, parties, RFC 3161 timestamp, Sigstore Rekor log entry, and archive.org snapshot. Args: proof_id: The proof identifier (e.g. "prf_20260310_143022_a1b2c3") |
| verify_proofA | Get a human-readable summary of what a proof certifies. Useful for explaining to a user or auditor what was independently verified, without reading raw JSON. Args: proof_id: The proof identifier (e.g. "prf_20260310_143022_a1b2c3") |
| get_usageA | Check your ArkForge API usage and remaining credits for the current period. Returns your tier (Free / Pro / Enterprise), proofs used, proofs remaining, and the reset date. |
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 4 tools
Each tool has a distinct and non-overlapping purpose: certify_call creates proofs, get_proof retrieves raw proof data, get_usage checks account status, and verify_proof provides human-readable summaries. There is no ambiguity about when to use which tool, as they target different stages of the proof lifecycle and administrative functions.
All tools follow a consistent verb_noun pattern with clear, descriptive names: certify_call, get_proof, get_usage, and verify_proof. The naming is uniform, using snake_case throughout, and the verbs (certify, get, verify) accurately reflect the actions without mixing conventions.
With 4 tools, this server is well-scoped for its purpose of providing cryptographic proof and verification services. Each tool serves a clear role in the workflow—creating, retrieving, verifying proofs, and managing usage—without being overly sparse or bloated, making it efficient for agents to navigate.
The tool set covers the core lifecycle of proof creation, retrieval, and verification, along with administrative usage checks. A minor gap exists in the lack of tools for managing or deleting proofs, but this does not hinder basic operations, and agents can still perform essential tasks without dead ends.