Skip to main content
Glama
Sign In
@spoc/mcp-bridge

@spoc/mcp-bridge

Official
by SPOC-App
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Issue a harness passport

spoc.harness.issue

Issues a signed harness passport for SPOC to witness, returning the envelope, signature, expiry, and a one-time reporting key for HMAC-authenticating events.

Instructions

Mint a signed harness passport SPOC will witness. Bearer auth (spk_live_...) upgrades the tier to principal-linked; otherwise anonymous. Returns the envelope, envelope signature, signing key version, expiry, and a one-time reporting_key for HMAC-authenticating reported events.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "scopes": "<scopes>"
    },
    "name": "spoc.harness.issue"
  }
}

Input Schema

NameRequiredDescriptionDefault
scopesYesScopes the harness may exercise (e.g. tools:web-search).
task_idNoOptional task id to bind the passport to.
trust_tierNoRequested tier. Ignored if it conflicts with the presented auth (bearer → principal-linked, X-Attested-Publisher → attested, otherwise anonymous).
ttl_secondsNoRequested TTL in seconds. Capped by trust tier.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the auth-to-tier mapping (bearer spk_live_... → principal-linked, otherwise anonymous) and enumerates the return payload including the one-time reporting_key, which is non-obvious behavior. It omits whether issuance is idempotent, whether a new passport invalidates a prior one, and any rate limits or error conditions.

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

Conciseness4/5

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

Three sentences, front-loaded with the core action, then auth behavior, then return values – a sensible order with no filler. It is dense and abbreviation-heavy ('SPOC', 'spk_live_...', 'HMAC'), which costs a little readability.

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

Completeness4/5

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

For a mutation tool with no annotations and no output schema, the description compensates well by describing the returned envelope, signature, key version, expiry, and reporting_key. Gaps remain around idempotency, failure modes, and tier-specific TTL caps, which matter for a credential-minting operation.

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

Parameters3/5

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

Schema coverage is 100%, so all four parameters are already documented in the schema, giving a baseline of 3. The description reinforces the auth-versus-trust_tier interaction and explains the purpose of the reporting_key, but adds no meaning about scopes syntax or how ttl_seconds is capped per tier beyond what the schema states.

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?

States a specific verb ('Mint/Issue') and a specific resource ('signed harness passport SPOC will witness'), so the agent knows exactly what is produced. It does not name or contrast with any sibling such as spoc.harness.get or spoc.harness.verify, so differentiation is left implicit.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance, no prerequisite ordering (e.g. issue before report/complete), and no statement of when to call this versus spoc.harness.get or spoc.harness.verify. The agent must infer the position of this tool in the harness lifecycle from the name alone.

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

Deploy Server

Other Tools