Skip to main content
Glama

list_certificate_signing_keys

Read-only

Use to find the public key for a certificate's key_id, including keys retired after a rotation. Free. Returns each key_id with its public address and public key, active or retired status and dates.

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": "list_certificate_signing_keys"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds genuinely non-obvious context: retired keys are included, the call is free, and the returned fields are enumerated. It stops short of stating ordering or whether output is paginated, but the annotation coverage lowers the bar.

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?

Three short sentences, front-loaded with the use case, then a cost signal, then the return shape. 'Free' earns its place as a cost hint; nothing is padded.

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?

With no output schema, the description correctly carries the burden of describing return values (key_id, public address, public key, status, dates). What remains missing is small: ordering and whether all keys are returned in one response.

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

Parameters3/5

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

The tool takes zero parameters, which would normally earn the baseline 4, but the description repeatedly references 'a certificate's key_id' as though it were an input. That creates a mismatch an agent could act on incorrectly; the schema is the only place that clarifies no arguments are accepted.

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?

The description names a specific verb+resource ('find the public key for a certificate's key_id') and clearly differentiates itself from list_certificates by scoping to signing keys, including retired ones. Minor ambiguity: it frames the operation around a 'key_id' lookup even though the tool takes no input, which makes it read like a targeted lookup rather than a full listing.

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?

'Use to find the public key...' establishes a clear use case, and mentioning retired-after-rotation keys implies a scenario where other key lookups would fall short. However, no sibling tool is named and there are no explicit when-not conditions, so routing between this and list_certificates is left to inference.

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