Spurvik EU AI Act

spurvik_setup_snippet

Read-onlyIdempotent

Return a setup snippet for openai, anthropic, google-genai, vercel-ai-sdk, mastra, openai-agents, or langgraph. Provider clients are wrapped with withSpurvik. The Vercel AI SDK snippet passes spurvikMiddleware to wrapLanguageModel. The Mastra snippet calls withSpurvikMastra. The OpenAI Agents snippet calls withSpurvikModelProvider. The LangGraph snippet calls withSpurvikLangGraph and spurvikInterrupt. The snippet is built from the installed spurvik exports (spurvik or spurvik-sdk, including spurvik/ai, spurvik/langgraph, spurvik/mastra, and spurvik/openai-agents). The disclosure label is a separate React client snippet that imports spurvik/react. riskTier is a sample value. Set your own classification (as provider or deployer); Spurvik does not classify your use case. The SDK logs the call and attaches an HMAC receipt. It does not mark content. Also accepts react.

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": {
      "target": "<target>"
    },
    "name": "spurvik_setup_snippet"
  }
}

Input Schema

Name	Required	Description	Default
`target`	Yes
`runtime`	No
`framework`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover the read-only/idempotent/closed-world profile, and the description adds real context beyond them: the snippet is built from installed spurvik exports, the SDK logs the call and attaches an HMAC receipt but does not mark content, and Spurvik does not classify the use case. The 'riskTier is a sample value / set your own classification' note prevents misuse of returned code. It stops short of saying what the return value actually is (string vs structured object).

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

Conciseness3/5

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

Purpose is front-loaded and each sentence carries technical detail, but the prose is dense and internally redundant, listing per-framework wrapper functions in a run-on series. 'Also accepts react' is tacked on at the very end instead of being folded into the opening target list, which is where an agent looks first.

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

Completeness3/5

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

No output schema exists, so the description should say what a 'snippet' is (a code string? per-file map?), and it doesn't. For a three-parameter tool with zero schema coverage, leaving runtime and framework undescribed and the return shape unstated makes the definition only marginally sufficient.

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

Parameters2/5

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

Schema coverage is 0%, so the description must carry all parameter meaning. It does list the target values (including react), but the `runtime` (node, next, vercel, supabase-edge) and `framework` parameters are never mentioned, and the overlap between `framework` and `target` enums is left unexplained.

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

Purpose5/5

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

States a specific verb ('Return a setup snippet') plus the exact resource and enumerates the eight provider targets, so the agent can tell immediately what it produces. It is clearly distinct from receipt-explanation and marking-hook siblings.

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?

Usage is strongly implied by the exhaustive target list ('for openai, anthropic, google-genai...'), so an agent knows this is the tool to call when scaffolding an integration. There is no explicit when-not guidance or mention of when a sibling would be preferred.

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

All Spurvik EU AI Act tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.