Skip to main content
Glama
Sign In

QuassLabs API

by com.quasslabs
OverviewDiscussionsAdmin

agent_card_lint

Read-onlyIdempotent

Static lint of an A2A (Agent2Agent) Agent Card, the JSON an agent publishes at /.well-known/agent-card.json. Checks conformance with A2A v1.0.1 and the 0.3 field names (both dialects accepted): required fields present and typed, URLs absolute https (http allowed for localhost), input and output modes that look like MIME types, skills with id, name, description and tags, duplicate skill ids, and security requirements that reference declared schemes. Scores discoverability: skill descriptions too short (under 20 chars) or too long (over 1,024) to route on, near-duplicate skills, missing examples or provider. Flags prompt-injection phrasing aimed at the model reading the card and hidden zero-width, bidi or tag characters (reported as U+XXXX, never echoed raw). Optionally checks an x402 payment declaration: every accepts entry needs scheme, network, payTo, asset, resource (https) and a sane atomic amount; x402 findings are reported separately and do not affect the card score. 512 KB request; first 200 skills, 50 items per list, 100 x402 entries. URLs are parsed, never fetched, and card signatures are not verified. Deterministic, no LLM.

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": {
      "agent_card": "<agent_card>"
    },
    "name": "agent_card_lint"
  }
}

Input Schema

NameRequiredDescriptionDefault
x402NoOptional x402 payment declaration (object or JSON string), checked separately from the card.
agent_cardYesThe Agent Card as a JSON object, or a string containing that JSON. Missing fields are findings, not errors, so send it as published.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare the safe read-only profile, yet the description still adds substantial operational detail: URLs are parsed but never fetched, signatures are not verified, output is deterministic with no LLM, zero-width/bidi/tag characters are reported as U+XXXX and never echoed raw, and x402 findings do not affect the card score.

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?

The definition is a single long block, but it is front-loaded with the verb, resource and dialect scope, and nearly every sentence adds a distinct check or limit. It is dense rather than padded, though the check enumeration could be broken into a short list for faster scanning.

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 two-parameter, read-only analyzer with no output schema, the description covers what is checked, what is explicitly out of scope (fetching, signature verification), and the limits that shape results. It stops short of describing the response shape (score value, findings list structure), which an agent must discover by calling.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: both A2A v1.0.1 and 0.3 dialects are accepted, missing fields are findings rather than errors, x402 is optional and scored separately, and hard limits (512 KB, 200 skills, 50 items per list, 100 x402 entries) govern input size.

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 and resource ('Static lint of an A2A Agent Card') plus the artifact's location (/.well-known/agent-card.json), and enumerates the exact checks performed. This clearly separates it from siblings like mcp_tool_lint and skill_lint, which target different artifacts.

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?

Usage is implied rather than stated: an agent must infer it should call this when it has a published Agent Card to validate. There is no explicit 'use this instead of X' routing to mcp_tool_lint or skill_lint, and no stated preconditions beyond 'send it as published'.

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

All QuassLabs API toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources