Start the device-flow authorization to attest works in this session (up to 20 attestations, 24h). Returns a link the USER must open in a browser and approve (anti-bot check included). After the user approves, call complete_authorization. Not needed if the connection already carries an API key header, or for verification tools.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: returns a user-opened browser link with anti-bot check, limits of 20 attestations and 24h, and the two-step flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey purpose, limits, user action, exceptional cases, and next step; no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the authorization flow, user interaction, limits, and relationship to siblings. Minor gap: no details on error handling or timeout.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds value by explaining the tool's purpose and flow beyond the parameterless schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts device-flow authorization for attestation, specifies limits (up to 20 attestations, 24h), and distinguishes from siblings by mentioning the alternative complete_authorization and exceptions for API key or verification tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use (to authorize attestations), when not (if API key header present, for verification tools), and directs to call complete_authorization after user approval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: authorization flow, attestation, verification, anchor checking, certificate lookup and creation, and health status. No overlapping responsibilities.
Most tools follow verb_noun pattern (attest_hash, check_anchor, etc.), but 'authorize' is verb-only and 'service_status' is noun_noun, causing minor inconsistency.
With 8 tools, the set is well-scoped for an attestation service, covering authorization, attestation, verification, certificate retrieval, anchor checking, and health monitoring.
Core workflow is covered (authorize, attest, verify, certificate), but lacks a tool to list all user attestations or manage sessions, a minor gap.