heron
Server Details
Free, signed trust scores for what an AI agent runs: skills, MCP servers, and the agent itself.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 11 of 11 tools scored. Lowest: 3.3/5.
Each tool targets a distinct aspect of security analysis (identity, red-teaming, MCP scan, skill scan, verification, etc.) with no overlapping purposes. Descriptions clearly differentiate them.
All tools follow a consistent 'heron_' prefix with descriptive noun phrases using snake_case. The pattern is uniform across all tools.
With 11 tools, the server is well-scoped for its purpose of AI agent security analysis. Each tool serves a clear function without unnecessary redundancy.
The tool set covers the full lifecycle: scanning agent prompts, MCP servers, and skills; identity lookup and verification; report retrieval with pricing negotiation; and methodology transparency. No obvious gaps.
Available Tools
11 toolsheron_agent_identityAInspect
Look up an agent's Heron identity: its wallet-signed passport and its portable, signed attestations (skill scans, MCP scans, red-team runs it has bound to its identity). Anyone can verify the signatures with heron_verify_attestation — reputation locked into no platform. To REGISTER your own identity, prove wallet control via the /identity/challenge + /identity/register API (you sign a Heron nonce with your own key).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read operation (lookup) with no side effects, but doesn't explicitly state safety, idempotency, or auth requirements.
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 concise sentences, front-loaded with core purpose. The second sentence adds context about registration but remains efficient.
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?
No output schema, no annotations, single parameter. Covers lookup purpose and mentions verification/registration, but lacks details on return structure or parameter format. Adequate but minimal.
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?
Schema has one required parameter 'name' with 0% schema description coverage. The description does not explain what 'name' refers to (e.g., agent name or identifier), so it adds no value beyond the 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 the tool looks up an agent's Heron identity (passport and attestations), distinguishing it from verification (heron_verify_attestation) and registration (separate API).
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?
Describes when to use (lookup) and directs registration to a different API. Mentions verification as related but doesn't explicitly compare to siblings like heron_agent_redteam.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
heron_agent_redteamAInspect
Red-team an AI agent's SYSTEM PROMPT for injection-resilience (static, safe — nothing
is sent anywhere). Pass the agent's system_prompt (and optionally its tools). Returns a
0-100 resilience score, a verdict (resilient / needs work / vulnerable), and concrete findings
with fixes: secrets baked into the prompt, missing trust boundary between instructions and
untrusted user/tool input, weakness to instruction-override / system-prompt extraction / role
hijack, and hidden/obfuscated instructions — plus a wallet-signed attestation. For LIVE probing
of an endpoint you own, use the proof-of-control-gated /redteam/verify + /redteam/live API. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| tools | No | ||
| system_prompt | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the operation is static, safe, and sends nothing anywhere. It also lists the return values (score, verdict, findings, attestation). However, it does not mention potential error conditions or rate limits, which would further enhance transparency.
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?
The description is concise and front-loaded, starting with the main purpose. Every sentence adds value, with no redundancy. It efficiently covers what, how, returns, and alternatives in a compact form.
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?
Given no output schema, the description adequately explains the return values (score, verdict, findings, attestation). It also covers the tool's scope and limitations. Some additional context on error handling or prerequisites could improve completeness, but it is sufficient for the tool's complexity.
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?
Schema coverage is 0%, so description must compensate. It explains that `system_prompt` is the main input and `tools` is optional, adding meaning beyond the schema. However, it does not detail the expected structure of the `tools` array, which could be improved.
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 the tool's purpose: to red-team an AI agent's system prompt for injection resilience. It specifies the verb ('red-team'), the resource ('SYSTEM PROMPT'), and distinguishes from siblings by mentioning the static, safe nature and contrasting with live probing via the API endpoints.
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?
The description explicitly states when to use this tool (static red-teaming) and when not to (for live probing), and provides alternative API endpoints ('/redteam/verify + /redteam/live'). This gives clear guidance on usage vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
heron_full_reportAInspect
Get the FULL Heron report (executive summary, all fixes, 30/60/90 roadmap) as machine-readable JSON. Pay-per-use over x402.
First call (no order): returns HTTP 402 details — pay the given USDC amount on
Base to the pay_to address, then call again with the returned `order` id to
receive the report. Designed for autonomous agents that hold a wallet.| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| order | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the pay-per-use behavior, the two-call protocol, and the return of HTTP 402 for payment. It does not cover failure modes or rate limits but provides essential behavioral context.
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?
The description is short (~75 words), front-loaded with the main purpose, then efficiently explains the payment flow. No unnecessary words or repetition.
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?
Given no output schema, the description mentions 'machine-readable JSON' but not structure. It explains the process well but omits the role of the 'url' parameter and error handling. Adequate but incomplete for a complex payment-gated tool.
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?
Schema description coverage is 0%. The description explains the 'order' parameter (returned from first call, default null) but not the 'url' parameter, leaving its purpose ambiguous. Only partial compensation for missing schema descriptions.
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 the verb ('Get') and resource ('FULL Heron report') with specifics (executive summary, all fixes, 30/60/90 roadmap). It distinguishes from sibling tools like heron_manifest and heron_score, which focus on different aspects.
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?
The description explains the two-step payment-gated usage: first call without order triggers payment, then second call with order id. It mentions being designed for autonomous agents with wallets. However, it does not explicitly state when not to use or list alternatives, but the process is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
heron_manifestBInspect
Heron service description, pricing and payment (x402) details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, authentication requirements, side effects, or data scope. The description carries the full burden but barely adds context beyond the tool name.
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?
The description is a single, concise sentence with no extraneous words. It front-loads the core purpose and is appropriately sized for the tool's simplicity.
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?
Given no parameters and no output schema, the description succinctly defines the tool's purpose. It covers the essential information but could benefit from mentioning the output nature (e.g., 'returns a structured manifest'). Still, it is complete enough for a zero-parameter tool.
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?
The tool has zero parameters and the input schema is fully covered (100%). Per guidelines, this gives a baseline of 4. The description adds no parameter-specific details, which is acceptable since there are none.
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 the tool provides 'service description, pricing and payment details', specifying a concrete resource. It distinguishes from sibling tools like heron_score or heron_agent_identity which cover different aspects. However, it lacks an active verb like 'retrieve' or 'get', and could be slightly more specific.
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?
No guidance is given on when to use this tool over siblings or what context is appropriate. The description does not mention prerequisites, alternatives, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
heron_mcp_scanAInspect
Check whether an MCP SERVER is SAFE TO CONNECT before you add it. An MCP server's
tool names, descriptions and schemas are injected into your context, and you will obey
instructions hidden there ("tool poisoning"). Provide EITHER url (a live remote MCP
endpoint — Heron connects READ-ONLY, reads tools/list, and NEVER calls a tool) OR tools
(a pasted tools/list array, for stdio/self-hosted servers). Returns a 0-100 trust score,
a verdict (trusted / caution / dangerous), and the findings: hidden agent-directed
instructions, data exfiltration, sensitive-parameter capture, tool shadowing, and obfuscated
payloads (Morse, base64, invisible Unicode, homoglyphs) — plus a wallet-signed attestation. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| tools | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses behavioral traits: connects read-only, reads tools/list, never calls a tool. Explains what it returns (trust score, verdict, findings, attestation) and what it looks for (hidden instructions, data exfiltration, etc.). Highly transparent.
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?
The description is a single paragraph but is dense with information. Front-loaded with main purpose. Every sentence adds value, though could be slightly more structured (e.g., bullet points for findings).
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?
No output schema, but description explains return values comprehensively: trust score (0-100), verdict, findings, and wallet-signed attestation. Covers what the tool does, how to use it, and what to expect. Very complete for a scanning tool.
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?
Schema descriptions coverage is 0%, but description adds meaning: explains that `url` is for a live remote endpoint and `tools` is for pasted tools/list array for stdio/self-hosted. Also implies mutual exclusivity (provide EITHER). Adds value beyond the 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 the tool's purpose: 'Check whether an MCP SERVER is SAFE TO CONNECT before you add it.' It uses specific verb 'check' and resource 'MCP server', and distinguishes from siblings by explaining the two modes (url vs 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?
Explicitly says when to use (before connecting an MCP server) and provides guidance on providing either url or tools. It mentions that with url, Heron connects read-only and never calls a tool. Does not explicitly exclude alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
heron_methodologyAInspect
How Heron computes a skill trust score — the public rules, severity weights, scoring formula and model. A signed attestation proves integrity, not correctness, so the method is open: audit it before you rely on a score.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits: the tool provides public rules and an attestation that proves integrity not correctness. Since no annotations are provided, the description carries the full burden and adequately conveys that this is a read-only informational tool with no side effects.
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?
The description is two sentences with no wasted words. It is front-loaded with the core purpose and adds a critical nuance about the attestation. Every sentence earns its place.
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?
Given that the tool is purely informational with no parameters and no output schema, the description covers the necessary context: what the tool provides and the caveat about the attestation. It is complete enough for an agent to understand its purpose and decide when to invoke it.
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?
The input schema has no parameters and schema coverage is 100%, so the baseline is 4. The description adds value by explaining the content of the tool (rules, weights, formula) but no parameter-level detail is needed.
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 the tool's purpose: explaining how Heron computes a skill trust score, including rules, weights, formula, and model. It distinguishes itself from sibling tools like 'heron_score' or 'heron_trust_index' by focusing on methodology rather than score computation or reporting.
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?
The description implies when to use the tool ('audit it before you rely on a score'), providing context for usage. However, it does not explicitly state when not to use it or contrast with alternative tools, which would improve the dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
heron_negotiateAInspect
Name-your-price for the full report. Propose bid (USD). If your bid is at
or above Heron's transparent floor it is accepted at that price (capped at the
list price); below the floor you get a counter-offer. Then pay the returned
x402 amount and call heron_full_report(url, order) to collect the report.
| Name | Required | Description | Default |
|---|---|---|---|
| bid | Yes | ||
| url | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without any annotations, the description carries full burden and does well: it explains the negotiation logic (bid compared to floor, acceptance capped at list price, counter-offer), payment step, and subsequent tool call. It lacks details on rate limits or authentication but the core behavior is well disclosed.
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?
The description is concise (two sentences covering purpose, conditions, and follow-up steps). It front-loads the main action. No wasted words, but could be slightly more structured with clear parameter labels.
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?
Given no output schema and no annotations, the description covers the negotiation flow, payment instruction, and next tool call. It is complete enough for an agent to understand the workflow, though edge cases (e.g., multiple counter-offers) are not addressed.
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?
Schema description coverage is 0%, so the description must compensate. It mentions 'bid (USD)' and implies 'url' refers to the report URL via context. However, it does not provide explicit parameter descriptions or default values, leaving some interpretation to the agent.
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 the tool is for name-your-price negotiation for a full report, with a specific process (bid, acceptance or counter-offer, payment, then calling heron_full_report). It distinguishes from siblings like heron_full_report by specifying that this is the negotiation step before retrieval.
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?
The description explicitly explains when to use the tool (to propose a bid for a report) and what to do next (pay and call heron_full_report on success or counter-offer). It also implies that this is an alternative to calling heron_full_report directly without negotiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
heron_scoreAInspect
Free instant AI-visibility (GEO) score for a URL: how citable the page is to AI search engines (ChatGPT, Claude, Perplexity, Gemini, Google AI Overviews). Returns overall 0-100 score, grade, per-dimension breakdown and a citability verdict. No payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states 'Free instant' and lists return types, but does not disclose rate limits, caching, or whether the tool is read-only. It does not contradict any annotations.
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?
The description is three sentences, front-loads the core purpose, and includes essential details without unnecessary words. Every sentence adds value.
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?
Given the tool's simplicity (one parameter, no output schema), the description reasonably covers functionality and return values. It could mention that the URL must be publicly accessible or valid, but overall it is sufficiently complete.
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?
The schema has one required parameter 'url' with 0% description coverage. The description adds minimal value beyond stating 'for a URL' but does not specify expected format (e.g., protocol, full URL). For a single parameter, the baseline is adequate but not enhanced.
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 the tool's purpose: providing a free AI-visibility (GEO) score for a URL. It specifies the verb ('score'), resource ('URL'), and differentiates from sibling tools like heron_full_report by emphasizing instant, free access. The description also lists the output components (score, grade, breakdown, verdict).
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?
The description implies when to use (for quick score) and mentions 'No payment required,' but lacks explicit guidance on when not to use or alternatives among siblings. There is no mention of prerequisites like public URL accessibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
heron_skill_scanAInspect
Check whether an agent SKILL.md skill is SAFE TO RUN before you install it.
Provide EITHER url (a GitHub link — repo, folder, or SKILL.md; Heron pulls the
manifest + its scripts) OR skill_md (the manifest text). Returns a 0-100 trust
score, a verdict (trusted / caution / dangerous), the specific findings (remote
code execution, secret/credential access, data exfiltration, wallet draining,
prompt-injection hidden in the manifest), what the skill CLAIMS vs what it
ACTUALLY does, and a wallet-signed attestation you can verify. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| skill_md | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a 0-100 trust score, verdict, specific findings, claim vs actual behavior, and an attestation. It also mentions that with a URL, Heron pulls the manifest and scripts. There is no contradiction with any annotations.
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?
The description is somewhat long but well-structured: first sentence states the purpose, then input options, followed by output details, and ends with 'Free.' Every sentence adds value, though it could be slightly more concise.
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?
Given the complexity of a security scan tool and the absence of an output schema, the description is comprehensive. It lists all key output components (score, verdict, findings, claim vs actual, attestation). It also explains the free nature. This fully equips an agent to understand what to expect.
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?
The input schema provides only titles and default values with no descriptions, so schema description coverage is 0%. The description adds substantial meaning: it explains that `url` is a GitHub link (repo, folder, or SKILL.md) and that Heron pulls the manifest and scripts, while `skill_md` is the manifest text. This goes far beyond the 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 that the tool checks whether an agent SKILL.md is safe to run before installation, using a specific verb ('Check') and resource ('skill'). It distinguishes itself from sibling tools like heron_agent_identity or heron_full_report by focusing on scanning a skill manifest for safety.
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?
The description explicitly tells the user to provide EITHER a `url` (GitHub link) OR `skill_md` (manifest text), covering both input modes. It does not explicitly state when not to use the tool or mention sibling tools as alternatives, but the guidance is clear and sufficient for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
heron_trust_indexAInspect
The public Heron skill-trust index: recently analyzed public agent skills with their 0-100 trust scores and verdicts. Use it to see what has already been vetted.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool is public and returns trust scores and verdicts, implying a read-only operation. However, it does not explicitly guarantee no side effects or detail the update frequency or scope of the index. A score of 3 is adequate for a non-destructive lookup tool.
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, front-loaded with the tool's identity and a clear usage directive. Every sentence adds value, and there is no redundant or vague language.
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 adequately explains what the tool returns (trust scores and verdicts) and its purpose. It could be improved by noting the scope (all vetted skills?) or whether the index is paginated, but overall it is sufficient for an agent to understand and use correctly.
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?
The input schema has zero parameters (100% coverage by default). The description adds meaning by explaining the output contains 0-100 trust scores and verdicts for recently analyzed skills, which is essential since the schema provides no clues. This compensates well for the lack of parameters.
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 the tool returns the public Heron skill-trust index with 0-100 trust scores and verdicts, and its purpose is to see what has already been vetted. This distinguishes it from sibling tools like heron_score (which likely gives a single score) and heron_skill_scan (which scans skills).
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?
The description says 'Use it to see what has already been vetted,' providing clear context for when to use this tool. It does not explicitly state when not to use it or name alternatives, but among siblings, the purpose is distinct enough that an agent can infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
heron_verify_attestationAInspect
Verify a Heron skill-attestation signature yourself (EIP-191) — confirms Heron's wallet signed this exact analysis digest. No trust in Heron required.
| Name | Required | Description | Default |
|---|---|---|---|
| digest | Yes | ||
| signature | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains that it performs EIP-191 verification and that no trust is required. However, it does not describe the return value or behavior on invalid input, which would be helpful for complete transparency.
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 with clear front-loading. Every sentence adds essential information, and there is no wasted text.
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?
Given the tool's simplicity (2 string parameters, no output schema), the description covers purpose and high-level behavior but misses return value details and input format requirements. This is adequate but leaves clear gaps for an agent.
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?
Schema coverage is 0%, and the description only vaguely mentions 'analysis digest' and 'signature' without specifying format (e.g., hex, string type). With no schema descriptions and minimal additional context, the description does not adequately compensate for the lack of parameter documentation.
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?
Clearly states the verb (verify), the resource (attestation signature via EIP-191), and the benefit (no trust in Heron). Distinguishes it from sibling tools like heron_skill_scan or heron_trust_index.
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?
Implies when to use: when one wants to independently verify a signature without relying on Heron. Lacks explicit exclusions or alternative tools, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!