ack-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ack_create_controller_credentialA | Create an unsigned W3C Verifiable Credential proving that a subject DID (e.g. an agent) is controlled by a controller DID (e.g. the owner). Pass the JSON output to ack_sign_credential to get a signed JWT. |
| ack_sign_credentialA | Sign a W3C Verifiable Credential, returning a signed JWT string. Pass the JSON output from ack_create_controller_credential or ack_create_payment_receipt as the credential parameter. The resulting JWT can be verified with ack_verify_credential or ack_verify_payment_receipt. |
| ack_verify_credentialA | Verify a signed credential JWT (from ack_sign_credential). Checks signature, expiration, and optionally trusted issuers. Set verifyControllerClaims to true to also verify the controller relationship against the subject's DID document (requires did:web or similar — did:key does not support this). Returns {valid: true/false}. |
| ack_resolve_didA | Resolve a DID URI to its DID Document. Supports did:key, did:web, and did:pkh methods. |
| ack_create_jwtA | Create a signed JWT with an arbitrary payload. Use for challenge-response authentication, signed messages between agents, or any custom signed payload. The JWT is signed with the provided JWK and includes the signer's DID as the issuer. |
| ack_verify_jwtA | Verify a signed JWT and return its decoded payload. Checks the signature against the issuer's DID. Use for verifying challenge-response tokens or any signed message from another agent. |
| ack_create_payment_requestA | Create a signed payment request token (JWT) for use in HTTP 402 responses. Unlike receipts, this creates AND signs in one step. Verify the result with ack_verify_payment_request. |
| ack_verify_payment_requestA | Verify and parse a payment request JWT (from ack_create_payment_request). Returns the decoded payment request if valid, including payment options and issuer. Returns {valid: true/false}. |
| ack_create_payment_receiptA | Create an unsigned payment receipt as a W3C Verifiable Credential. The output is unsigned JSON — you must pass it to ack_sign_credential with the receipt issuer's JWK and DID to get a signed JWT, then verify it with ack_verify_payment_receipt. |
| ack_verify_payment_receiptA | Verify a signed payment receipt JWT (from ack_sign_credential after ack_create_payment_receipt). Checks receipt signature, receipt claims, and optionally the embedded payment request. Returns {valid: true/false}. |
| ack_generate_keypairA | Generate a new cryptographic keypair with a did:key DID. Returns the JWK (private key), DID, and curve. Pass the jwk value to any tool that requires signerJwk. The DID can be used as signerDid, subjectDid, controllerDid, etc. |
| ack_create_did_webA | Create a did:web DID URI from a URL. Use for agents or services hosted at a known web address. The domain must host a .well-known/did.json document for DID resolution to work. |
| ack_create_did_pkhA | Create a did:pkh DID URI from a blockchain chain ID and wallet address. Use for representing on-chain identities (e.g. Ethereum wallets) as DIDs. |
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 13 tools
Most tools target distinct operations: DID creation, key generation, JWT handling, and payment flows are clearly separated. The only potential confusion is between sign/verify JWT and sign/verify credential, but the descriptions make the arbitrary-payload vs. W3C-credential distinction clear.
All tools follow the consistent ack_<verb>_<noun> pattern, e.g., create_did_web, verify_credential, generate_keypair. There are no mixed conventions or vague generic names.
13 tools is well within the ideal range for a domain spanning DIDs, JWTs, verifiable credentials, and payment receipts. Each tool covers a distinct step in the identity/payment workflow without obvious redundancy.
The core lifecycle is well covered: keypair generation, DID creation/resolution, JWT sign/verify, credential sign/verify, and the payment request/receipt flow. Minor gaps exist, such as no generic credential-creation tool or revocation mechanism, but most workflows are composable from the provided operations.