Skip to main content
Glama

self_test

Validate sample receipt and bundle to prove the verifier works offline.

Instructions

Verify the packaged sample receipt and sample bundle to prove the verifier works offline.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • server.js:167-191 (registration)
    Registration of the 'self_test' tool via server.tool() with name 'self_test', description, empty schema {}, and an async handler.
    server.tool(
      'self_test',
      'Verify the packaged sample receipt and sample bundle to prove the verifier works offline.',
      {},
      async () => {
        try {
          const { receipt, bundle, publicKeyHex } = loadSelfTestArtifacts();
          const receiptResult = verifySingle(receipt, publicKeyHex);
          const bundleResult = verifyBundle(bundle);
          return textResult({
            ok: receiptResult.valid && bundleResult.valid,
            receipt: receiptResult,
            bundle: {
              valid: bundleResult.valid,
              total: bundleResult.total,
              passed: bundleResult.passed,
              failed: bundleResult.failed,
            },
            note: 'No ScopeBlind servers were contacted.',
          });
        } catch (error) {
          return textResult({ ok: false, error: error.message });
        }
      }
    );
  • Handler function for 'self_test': loads sample artifacts, calls verifySingle() and verifyBundle(), and returns combined result.
    server.tool(
      'self_test',
      'Verify the packaged sample receipt and sample bundle to prove the verifier works offline.',
      {},
      async () => {
        try {
          const { receipt, bundle, publicKeyHex } = loadSelfTestArtifacts();
          const receiptResult = verifySingle(receipt, publicKeyHex);
          const bundleResult = verifyBundle(bundle);
          return textResult({
            ok: receiptResult.valid && bundleResult.valid,
            receipt: receiptResult,
            bundle: {
              valid: bundleResult.valid,
              total: bundleResult.total,
              passed: bundleResult.passed,
              failed: bundleResult.failed,
            },
            note: 'No ScopeBlind servers were contacted.',
          });
        } catch (error) {
          return textResult({ ok: false, error: error.message });
        }
      }
    );
  • Helper function loadSelfTestArtifacts() that loads sample-receipt.json and sample-bundle.json from the 'samples' directory plus a hardcoded public key hex.
    function loadSelfTestArtifacts() {
      return {
        receipt: JSON.parse(readFileSync(join(__dirname, 'samples', 'sample-receipt.json'), 'utf-8')),
        bundle: JSON.parse(readFileSync(join(__dirname, 'samples', 'sample-bundle.json'), 'utf-8')),
        publicKeyHex: 'd75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a',
      };
    }
  • Helper function verifySingle() used by the self_test handler to verify a single artifact with a public key.
    function verifySingle(artifact, publicKeyHex) {
      const core = getArtifactCore(artifact);
      const key = publicKeyHex || deriveEmbeddedKey(artifact);
      if (!key) {
        return {
          valid: false,
          error: 'no_public_key',
          type: artifact?.type || core.artifact?.type || 'unknown',
          format: core.format,
          kid: core.kid,
          issuer: artifact?.issuer || null,
          hash: null,
        };
      }
    
      const result = verifyArtifact(core.artifact, key);
      const unsigned = { ...core.artifact };
      delete unsigned.signature;
    
      return {
        valid: !!result.valid,
        error: result.valid ? null : (result.error || 'invalid_signature'),
        type: artifact?.type || core.artifact?.type || 'unknown',
        format: core.format,
        kid: core.kid,
        issuer: artifact?.issuer || null,
        hash: canonicalHash(unsigned),
      };
    }
  • Helper function verifyBundle() used by the self_test handler to verify all receipts in a bundle.
    function verifyBundle(bundle) {
      if (!bundle?.receipts || !Array.isArray(bundle.receipts)) {
        throw new Error('Invalid bundle: missing receipts array');
      }
      const keyMap = resolveBundleKeyMap(bundle);
      let passed = 0;
      const receipts = bundle.receipts.map((receipt, index) => {
        const key = receipt?.kid ? keyMap.get(receipt.kid) : deriveEmbeddedKey(receipt);
        const result = verifySingle(receipt, key || null);
        if (result.valid) passed += 1;
        return {
          index,
          type: result.type,
          kid: result.kid,
          valid: result.valid,
          error: result.error,
        };
      });
      return {
        valid: passed === bundle.receipts.length,
        total: bundle.receipts.length,
        passed,
        failed: bundle.receipts.length - passed,
        receipts,
      };
    }
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist; the description adequately indicates this is a test operation with no destructive side effects. However, it doesn't disclose any potential outputs or prerequisites, though minimal for a zero-parameter tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence that is concise and front-loaded, containing no superfluous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter test tool with no output schema, the description sufficiently covers its purpose and context. No additional details are necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has zero parameters, so baseline score 4 applies. Description adds no parameter information, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool verifies sample receipt and bundle to prove offline functionality. It implicitly distinguishes from siblings (verify_bundle, verify_receipt) which likely handle real data, but doesn't explicitly differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for testing the verifier offline, but lacks explicit guidance on when to use this tool versus verify_bundle/receipt. No when-not or alternative instructions provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

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/ScopeBlind/verify-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server