trustlayer
Server Details
FeedOracle Trust Layer - 10-tool cross-server trust: signing, anchoring, verification.
- 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 3.8/5 across 10 of 10 tools scored.
Each tool addresses a distinct aspect of the trust layer: reputation, confidence gating, evidence anchoring, freshness, signed facts, hallucination detection, provenance, infrastructure status, claim verification, and signature verification. There is no ambiguity between them.
All tool names use snake_case, which is consistent, but the verb usage varies (e.g., 'get_signed_fact', 'verify_claim', 'trust_status'). While readable, a uniform verb_noun pattern (e.g., all starting with verbs) would improve predictability.
With 10 tools, the server is well-scoped for a trust layer. Each tool provides a necessary function without redundancy, balancing coverage and simplicity.
The tool set covers core trust operations: reputation, confidence, evidence anchoring, freshness, verification, and provenance. Minor gaps exist, such as the absence of tools for updating or revoking anchored evidence, but the surface is largely complete for its domain.
Available Tools
10 toolsagent_reputationBInspect
Get trust score and reputation for an AI agent from FeedOracle KYA (Know Your Agent) system. Returns trust level (UNVERIFIED → CERTIFIED), score (0-100), and registration details.
| Name | Required | Description | Default |
|---|---|---|---|
| client_id | No | Agent's client_id from KYA registration | |
| agent_name | No | Agent name to search (if client_id unknown) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions return values but does not address read-only nature, authentication requirements, rate limits, or side effects. The tool retrieves data, but this is implicit.
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, focused sentence that front-loads the action and resource. Every word adds value, and there is no extraneous information.
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 simple tool (2 optional params, no output schema), the description adequately explains the return types (trust level, score, registration details). It could clarify whether parameters are mutually exclusive or if both can be used, but overall completeness is high.
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 100%, and both parameters have clear descriptions. The tool description adds minimal extra meaning beyond restating the schema. Baseline 3 is appropriate.
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 action ('Get'), the resource ('trust score and reputation for an AI agent from FeedOracle KYA'), and the specific outputs (trust level, score, registration details). It differentiates from sibling tools by specifying the KYA system, which is unique among the listed siblings.
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 does not provide any guidance on when to use this tool versus its siblings (e.g., trust_status, verify_claim). No exclusions or alternative recommendations are given, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
confidence_gateAInspect
Decision gate for agents: should I proceed, exercise caution, abstain, or escalate? Evaluates multi-factor confidence for a specific action type (cite, trade, report, recommend) against a threshold.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Token to evaluate | |
| action_type | No | What the agent wants to do: cite, trade, report, recommend | cite |
| min_confidence | No | Minimum confidence to proceed (0-100, default: 70) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral details. It mentions 'multi-factor confidence' and threshold evaluation, but does not explain the factors, confidence calculation, or output format, leaving significant gaps.
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, front-loaded with the core purpose, and contains 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?
Given three parameters and no output schema, the description provides a high-level purpose but lacks details on output and behavioral specifics, making it adequate but incomplete.
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?
With 100% schema coverage, the descriptions in the schema already explain the parameters. The tool description adds context about action types matching the action_type parameter, but adds little 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 is a decision gate for agents, listing specific outcomes (proceed, caution, abstain, escalate) and action types (cite, trade, report, recommend). This distinguishes it from sibling tools like hallucination_check or trust_status.
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 usage when an agent needs to make a decision based on confidence, but does not explicitly state when not to use it or mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evidence_anchorAInspect
Anchor a fact on-chain (Polygon) as immutable, timestamped evidence. Creates an append-only registry entry with pack_id and content hash. Tamper-proof audit trail.
| Name | Required | Description | Default |
|---|---|---|---|
| fact | Yes | The fact to anchor | |
| symbol | No | Related token symbol (optional) | |
| framework | No | Framework context: trust_layer, mica, dora | trust_layer |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a decent job by highlighting append-only, tamper-proof, timestamped behavior. However, it lacks details on costs, authorization, or what happens on duplicates.
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, no unnecessary words, front-loaded with the core action. Every sentence adds value and the structure is 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?
For a tool with 3 parameters and no output schema, the description covers the core purpose and key behavioral properties. It could mention what the function returns (e.g., transaction hash) to be fully 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?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning to the parameters (fact, symbol, framework) beyond what is in the schema, and does not explain pack_id or content hash which appear only in the description.
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 uses a specific verb 'anchor' and resource 'fact on-chain (Polygon)', clearly stating the purpose of creating immutable, timestamped evidence. It distinguishes from sibling tools that deal with reputation, confidence, verification, etc.
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 usage for anchoring facts on-chain but provides no explicit guidance on when to use this tool versus alternatives like provenance_trace or verify_claim. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
freshness_guardBInspect
Check if data is current, stale, or expired. Prevents agent decisions based on outdated information. Configurable max age threshold.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Token symbol (optional — checks overall feed if omitted) | |
| max_age_seconds | No | Maximum acceptable age in seconds (default: 300) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It mentions checking freshness and a configurable threshold, but fails to describe the return format (e.g., boolean, status string, or data object) or error handling. This is a significant gap for a tool that likely returns a judgment.
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?
Three sentences, front-loaded with purpose and key use case. No wasted words, though a fourth sentence on return value would improve completeness without harming conciseness.
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 optional params, no output schema) and no annotations, the description covers purpose and usage adequately. However, missing return behavior and integration notes with sibling tools limits completeness.
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 100% with descriptions for both parameters. The description adds context: symbol is optional and checks overall feed if omitted, and max_age_seconds has a default of 300. This is adequate but does not significantly enhance 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 states the tool checks if data is current, stale, or expired, clearly specifying its verb (check) and resource (freshness). It distinguishes from siblings like trust_status or confidence_gate by focusing on data recency.
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 usage when decisions depend on data currency ('Prevents agent decisions based on outdated information'), but lacks explicit when-to-use vs alternatives or when-not-to-use guidance. No sibling differentiation for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_signed_factAInspect
Get a cryptographically signed, machine-verifiable fact. Returns ES256K-signed data with JWKS verification URL. Other agents can independently verify the signature.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Token symbol: USDC, RLUSD, EURC, USDT, DAI | |
| fact_type | No | Type: price, peg, market_cap, reserve | price |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses signing algorithm (ES256K), presence of JWKS verification URL, and verifiability by other agents. It reveals no destructive side effects, and the behavior is consistent with a read operation.
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, front-loading the core purpose. Every sentence adds value, with no verbosity.
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 exists, but the description does not explain the return format (e.g., structure of the signed data). For a tool that returns complex signed data, this is a gap, though the core purpose is clear.
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 100% coverage, with enums and descriptions for both parameters. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.
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 uses specific verbs ('Get') and a clear resource ('cryptographically signed, machine-verifiable fact'). It distinguishes from sibling tools like verify_signature by focusing on retrieving signed data rather than verifying it.
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 states the tool returns signed data with a verification URL and notes that other agents can independently verify. While it doesn't explicitly list when not to use alternatives, the context of siblings like verify_claim makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hallucination_checkAInspect
Compare an agent's statement against ground truth evidence. Detects factual mismatches and dangerous hallucination patterns (absolute language, suspect claims). Returns evidence checks and red flags.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional context for the statement | |
| statement | Yes | The statement to check against evidence |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes the operation as a check and lists what it detects, but does not clarify if it is read-only, requires authentication, or has side effects. The description is adequate but lacks depth.
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 no wasted words. The verb is front-loaded, and every sentence contributes meaningful information.
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 purpose, detection patterns, and output types. It is fairly complete, though agents might benefit from knowing the source of ground truth or latency characteristics.
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 100% with descriptions for both parameters. The description adds context about output (evidence checks, red flags) but does not enhance input semantics beyond what the schema provides. Baseline 3 is appropriate.
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?
Description clearly states the verb ('Compare'), resource ('agent's statement against ground truth evidence'), and specific outputs ('evidence checks and red flags'). It distinguishes from siblings by focusing on hallucination patterns like absolute language and suspect claims.
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 explicit guidance on when to use this tool versus alternatives like verify_claim or confidence_gate. The description does not specify prerequisites 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.
provenance_traceAInspect
Full data provenance chain — traces every data point from external source (CoinGecko, ESMA, on-chain) through FeedOracle processing to final delivery. Each step individually hashed. Supports EU AI Act Art. 13 transparency requirements.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Token symbol to trace |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that each step is hashed, but no annotations exist; description does not clarify read-only nature or potential side effects, leaving some ambiguity for a mutation-unspecified 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 concise sentences front-loaded with core function and regulatory relevance, with no wasted 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?
Covers sources and processing but omits output format or result structure; without an output schema, more detail on the trace result would improve completeness.
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 already fully describes the 'symbol' parameter; the description adds no extra meaning beyond what the schema provides, meeting baseline expectation.
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?
Description states specific verb 'trace' and resource 'data provenance chain', clearly distinguishing from sibling tools like 'agent_reputation' or 'verify_claim'.
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 mentions regulatory support (EU AI Act Art. 13), providing a strong usage context, but does not specify when not to use or mention sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trust_statusAInspect
Trust Layer infrastructure health, capabilities, and component status. Shows which verification services are online and what the Trust Layer can do.
| 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 the read-only nature by stating it shows health and status, and there are no annotations to contradict. It does not mention side effects, which are absent for a status 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 concise sentences that are front-loaded with the main purpose, with no wasted 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?
Given zero parameters and no output schema, the description fully covers what the tool does and what it returns, making it complete for its simple functionality.
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?
Input schema has no parameters; description adds value by explaining the output (health, capabilities, component status) without needing to document 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 provides Trust Layer infrastructure health, capabilities, and component status, distinguishing it from sibling tools that perform specific verification or reputation operations.
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 use for checking overall health but lacks explicit guidance on when to use this vs alternatives, which are all clearly different in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_claimBInspect
Verify an agent's claim against FeedOracle signed evidence. Checks if a statement (e.g. 'USDC market cap is $32B') matches live, cryptographically signed data. Returns verified/partially_verified/unverified with confidence score and recommended action.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | The claim to verify, e.g. 'USDC has $32B market cap' | |
| symbol | No | Token symbol (auto-detected from claim if omitted) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses return values ('verified/partially_verified/unverified' with confidence score and recommended action), which is good. However, it omits behavioral traits like authentication needs, rate limits, or whether the tool is read-only. The mention of 'cryptographically signed data' hints at security but not comprehensively.
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 with only two sentences, each carrying essential information. It is front-loaded with the main action and provides clear output expectations. However, it could benefit from a more structured format, such as listing outputs.
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 lack of an output schema, the description adequately covers the return types (three states, confidence score, recommended action). However, it does not explain the meaning of 'partially_verified' or the range of recommended actions, leaving gaps for an agent to fully understand the tool's behavior.
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 100% with descriptions for both parameters. The description adds context via an example and mentions auto-detection for symbol, but this is already present in the schema's symbol description. No new semantic meaning beyond what the schema provides.
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 function: verifying a claim against FeedOracle signed evidence. It provides a concrete example, making the purpose specific and actionable. However, it does not explicitly differentiate from sibling tools like 'hallucination_check' or 'provenance_trace', which could lead to ambiguity in tool selection.
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 (to check a factual statement against signed data) but lacks explicit guidance on when not to use it or potential alternatives. No exclusions or prerequisites are mentioned, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_signatureAInspect
Verify a JWS or DSSE signature from FeedOracle evidence. Confirms cryptographic integrity and origin authenticity. Public JWKS at /.well-known/jwks.json.
| Name | Required | Description | Default |
|---|---|---|---|
| jws | No | JWS token to verify | |
| content_hash | No | Content hash to verify (sha256:...) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It mentions cryptographic integrity and origin authenticity and references the public key source, but does not disclose failure behavior, side effects, or required permissions.
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 concise sentences with front-loaded purpose and a helpful reference to the JWKS location. 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?
For a simple verification tool without output schema or annotations, the description covers the core purpose, what it confirms, and required key source. It could mention expected behavior on invalid signatures, but overall is adequate.
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 100%, so the schema already describes both parameters. The description adds no additional meaning beyond the schema, though it mentions DSSE while the schema only describes JWS, which could cause confusion.
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 verifies JWS or DSSE signatures from FeedOracle evidence, with a specific verb (verify) and resource (signature). It distinguishes from sibling tools like verify_claim, which focus on claims.
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 indicates use for verifying signatures from FeedOracle evidence and provides the JWKS location, but does not explicitly state when to use this tool versus alternatives like verify_claim.
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!