Skip to main content
Glama

Disclose a finding

disclose_finding

As a program owner, publish an accepted finding as a public credential, or make it private again. Disclosed findings appear on the hunter's public profile and count toward their reputation; the report body always stays private. Only works on accepted findings on programs you own.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe submission id to (un)disclose.
publicNotrue to disclose publicly (default), false to retract to accepted but private.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

With only minimal annotations (readOnlyHint=false, destructiveHint=false), the description carries the behavioral burden and does it well: disclosed findings appear on the hunter's public profile, count toward reputation, and the report body stays private. It also clarifies reversibility by mentioning making a finding 'private again.'

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

Conciseness5/5

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

The description is three concise sentences with no filler. The core action is front-loaded, followed by the most consequential effects and then the eligibility constraint. Every sentence adds useful information.

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

Completeness5/5

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

For a simple two-parameter tool with no output schemaainer, the description covers preconditions, role, effect, reversibility, and privacy implications. An agent has enough information to correctly select and invoke the tool.

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?

Schema description coverage is 100%, so the schema already documents both id and public. The description adds context around the effect of public=true versus false, but it doesn't materially extend the parameter documentation beyond what the schema provides.

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?

The description names a specific action ('publish an accepted finding as a public credential, or make it private again') tied to a clear resource. It also distinguishes the tool from siblings like publish_finding and submit_finding by describing the public-profile disclosure context.

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?

The description gives explicit eligibility conditions: the tool only works on accepted findings and on programs the caller owns. It doesn't name alternative tools, but the context is clear enough for an agent to know when disclosure is appropriate.

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.