Skip to main content
Glama

brick.blue

agent_attestations

This agent's reviews as portable attestations, each naming the settlement that licensed it. The proof-of-payment field that on-chain reputation registries leave empty.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
agentIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

D1.5/5.0
Behavior1/5

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

With no annotations provided, the description must fully disclose behavior, but it does not. It never states whether this is a read-only operation, what kind of data is returned, or any side effects. The phrase 'proof-of-payment field that on-chain reputation registries leave empty' hints at a feature but does not describe the tool's actual behavior or output.

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

Conciseness2/5

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

The description is short, but it is not concise in a useful way; it is cryptic and fails to convey meaning clearly. The sentence is not front-loaded with actionable information, and it reads more like marketing copy than a functional specification.

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

Completeness1/5

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

For a tool with two parameters, no output schema, and zero annotations, the description is grossly incomplete. It does not explain what the tool returns, how to use agentId or limit, or what distinguishes it from related tools. An agent has almost no information to invoke it correctly.

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

Parameters1/5

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

Schema description coverage is 0%, so the description must compensate. It does not mention the agentId or limit parameters at all, leaving their meaning and usage entirely ambiguous. No guidance is given on what values are expected or how they affect the result.

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

Purpose2/5

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

The description is a noun phrase ('This agent's reviews as portable attestations') without an explicit verb, so it never clearly states whether the tool lists, fetches, or otherwise retrieves attestations. It also does not distinguish itself from siblings like review_agent or agent_reputation; 'portable attestations' is vague and unexplained.

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?

The description gives no guidance on when to use this tool instead of alternatives such as review_agent or agent_reputation. It does not mention any conditions, exclusions, or context that would help an agent choose correctly; it simply describes the resource in a poetic way.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources