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

@spoc/mcp-bridge

Official
by SPOC-App
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Issue an anonymous test harness

spoc.harness.test

Run a no-auth, rate-limited echo test with a fixed test:echo scope and 300-second TTL to validate connectivity before wiring up the full flow.

Instructions

Anonymous test harness with the fixed scope test:echo and a 300s TTL. No auth required, tight rate limit (1 per 10 seconds per IP). Ideal for a hello-world before wiring up the full flow.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "spoc.harness.test"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so well: it discloses that no auth is required, the scope is fixed and non-configurable, the TTL is 300 seconds, and there is a tight rate limit of 1 per 10 seconds per IP. These are exactly the operational constraints an agent needs to avoid failures and retry storms.

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?

Three short sentences, each earning its place: identity/config first, then constraints (auth, rate limit), then recommended use. No repetition of the tool name and no filler.

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 zero-parameter, no-output-schema tool the description covers config and limits thoroughly. The one residual gap is that it does not say what comes back from issuing the harness, such as an identifier or short-lived credential, which the agent must discover by calling it or via a sibling.

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?

The tool takes zero parameters, so the baseline is 4. The description appropriately spends no words on parameter meaning and instead covers fixed configuration the agent cannot influence, such as scope and TTL.

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 resource and its fixed configuration: an anonymous test harness scoped to test:echo with a 300s TTL. That is more concrete than the title alone. It does not explicitly contrast itself with the sibling spoc.harness.issue, though the 'hello-world before wiring up the full flow' phrasing implicitly frames it as the lightweight variant.

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

Usage Guidelines4/5

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

"Ideal for a hello-world before wiring up the full flow" gives clear when-to-use context, positioning this as a smoke-test step prior to full harness provisioning. It stops short of naming the alternative (spoc.harness.issue) or stating when not to use it, so it is clear context without explicit exclusions.

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