agentshield-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.1.0
Disambiguation4/5
The scanning tools (verify_contract, scan_contract, deep_scan) have clear tiering but still overlap in purpose, which could cause an agent to pick the wrong one. Other tools like get_alerts, get_stats, and get_dashboard are distinct. Overall, most tools have clearly differentiated roles.
Naming Consistency2/5
Tool names mix verb-first (get_alerts, verify_contract, monitor_wallet) with noun-first (contract_diff) and adverb forms (deep_scan). The inconsistent use of get_ for reads but not for other actions makes naming unpredictable.
Tool Count3/5
At 19 tools, the set is on the heavier side, including gamification features (referrals, leaderboard, giveaways) that are tangential to the core security mission. Still, the core security tools are well-scoped, so the count is not excessive.
Completeness3/5
Coverage is solid for scanning, verification, and wallet monitoring, but missing an unfreeze tool creates a dead end after freeze_wallet. Webhook management is minimal (register only), and there is no way to view or manage monitored wallets directly.
Average 3.8/5 across 19 of 19 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation via 'View' but does not describe the return format, error handling, or any side effects. 'Requires API key' is a prerequisite already present in the schema, adding no new transparency.
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 a single sentence with no filler. It front-loads the action and lists key content areas, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple dashboard view, the description adequately lists the information areas, but with no output schema, it could mention what the response contains more specifically. It lacks details on response structure or potential limitations, though the tool is likely straightforward.
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 coverage is 100%, and the only parameter 'api_key' is already described as 'AgentShield API key'. The description merely repeats the requirement without adding any new semantic meaning. Baseline of 3 applies due to high schema coverage.
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 clearly states the tool's function: 'View your API usage, billing, active webhooks, and alerts.' It uses a specific verb and resource listing. However, it overlaps with sibling tools like get_alerts and get_stats, so it doesn't fully distinguish itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_alerts or get_stats. It neither mentions exclusions nor names alternative tools. With 18 siblings, this is a missed opportunity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states that higher reputation means more benefits, but does not describe operational traits such as whether it is a read-only operation, authentication requirements, or rate limits.
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 a single sentence with a parenthetical tier list, making it extremely concise and front-loaded. Every word contributes to defining the tool's purpose without redundancy.
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?
For a simple getter with two optional parameters, the description adequately conveys the return value (score and tier) and the meaning of tiers. Although no output schema exists, the tier list provides sufficient context for typical use cases.
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 coverage is 100% with both parameters (agent and api_key) already described in the input schema. The description adds no additional parameter semantics, so the baseline of 3 applies.
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 clearly states the tool retrieves an agent's reputation score and tier, listing the specific tier values (NEW, ACTIVE, VERIFIED, TRUSTED). This specific verb+resource combination distinguishes it from sibling tools like get_stats and get_leaderboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It neither mentions alternative reputation-related tools nor any conditions under which this tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the differential nature (since last check) and access tier, but omits prerequisites (e.g., whether a previous scan is required), whether the operation is read-only, and any side effects like storing state.
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 a single, front-loaded sentence with no redundant wording. It efficiently packs the action, target, attributes, temporal scope, and access restriction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity and no output schema or annotations. The description does not explain the return format or the prerequisite of a prior check, leaving an agent without critical context for a differential analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%: 'chain' lacks a description. The description does not clarify valid chain values or how parameters interact, and it adds no meaning beyond the schema's existing descriptions for contract and api_key.
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 uses a specific verb 'Detect' and clearly identifies the resource (contract) and the exact attributes monitored (ownership, proxy implementation, mint authority, taxes, honeypot status). The temporal qualifier 'since last check' distinguishes this from one-time scans like scan_contract or deep_scan.
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?
The description implies a use case: monitoring changes over time, but it does not explicitly contrast with sibling tools (e.g., scan_contract for initial checks) or state when not to use. The 'Pro/Builder only' note is an access restriction, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It merely states the action without mentioning side effects, authentication requirements, rate limits, or return structure. Even as a read operation, the absence of any safety or behavioral context is a noticeable gap.
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 a single, clear sentence with no unnecessary words. It front-loads the core action and resource, making it immediately scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter read tool, the description covers the core functionality adequately. However, with no annotations and no output schema, it omits details about response format, error behavior, or any operational constraints, making it minimally viable but not comprehensive.
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 input schema provides 100% description coverage for both parameters (wallet and limit), so the schema already documents their meaning. The description adds no additional parameter-level insight beyond what is already in the schema, aligning with the baseline.
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 specifies the verb 'Get' and the resource 'recent drain alerts and threat notifications' for a wallet address, clearly distinguishing it from sibling tools like monitor_wallet or get_stats. The scope is explicit and unambiguous.
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?
The description implies usage for checking alerts on a wallet but provides no explicit guidance on when to use this tool versus alternatives such as monitor_wallet or get_stats. No exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a read-only retrieval operation via the verb 'Get' and enumerates the returned statistics, which is useful. However, it does not explicitly confirm no side effects, mention any authentication needs, or describe the response structure, leaving some ambiguity.
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 a single, well-structured sentence that front-loads the key information. Every word adds value, and the three listed stat categories are concise and clear.
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?
Given the simplicity (0 params, no output schema), the description adequately conveys what the tool returns by listing the stat categories. It could optionally mention the response format, but for a parameterless stats call, the provided information is sufficient to invoke and understand the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The baseline of 4 applies because the empty schema covers all parameters, and the description correctly doesn't waste space on parameter details.
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 clearly states the tool's purpose: 'Get AgentShield platform statistics' with a specific list of metrics (contracts verified, wallets monitored, threats blocked). This distinguishes it from sibling tools like get_alerts or get_dashboard, though it doesn't explicitly call out the differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_dashboard or get_alerts. The description only states what it does, leaving the agent to infer usage context without any explicit exclusions or preferences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does state the primary effect (adding 500 free API calls), but it does not disclose whether redemption is one-time, whether the API key is validated, or error behavior. These are important behavioral traits for a tool that consumes codes and modifies account quota.
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 a single sentence, front-loaded with the action and benefit. It is concise and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two fully documented parameters, and the description explains the core behavior and outcome. However, it lacks usage guidelines and critical behavioral disclosures (e.g., one-time use, validation), which leaves some gaps for an agent deciding to invoke it.
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 input schema already fully documents both parameters (code and api_key) with descriptions, giving 100% coverage. The description adds no additional parameter-level nuance, so baseline 3 is appropriate.
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 uses a specific verb 'redeem' and resource 'referral code', clearly stating the outcome (+500 free API calls). It distinguishes from sibling tools like create_referral, which creates codes, and enter_giveaway, which is a different promotion type.
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?
The description clearly implies when to use the tool (when you have a referral code to redeem), but it does not explicitly provide context on alternatives or exclusions. No mention of conditions like having an active API key or that the code can only be used once.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only repeats the API key requirement already in the schema and doesn't explain side effects (e.g., whether the name overwrites the previous one, is reversible, or returns confirmation). This is a significant gap for a mutating tool.
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 concise, with two short sentences that front-load the purpose. No unnecessary words. It earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but with no annotations or output schema, the description should clarify what the operation does beyond just setting the name. It provides the core purpose and requirement, but lacks details on outcomes or error conditions, leaving some gaps.
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 input schema already provides complete descriptions for both parameters (name and api_key), including the max character limit. The description adds no new parameter semantics beyond what the schema states, so the baseline score of 3 applies.
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 clearly states the tool's function with a specific verb ('Set') and resource ('display name on the leaderboard'). This distinguishes it from sibling tools like get_leaderboard, which are read-only. The description is unambiguous and specific.
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 implies the use case (when you need to change your display name) and notes the API key requirement. However, it does not explicitly compare with alternatives or state exclusions. Context is clear, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently mentions the cost ($0.001 via x402 micropayment) and the types of risks detected. However, it does not state whether the operation is read-only, what happens if payment is omitted (though the schema hints at it), or describe the return format/results structure, leaving some behavioral aspects undisclosed.
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 two sentences, front-loaded with purpose, and includes a direct, actionable instruction. Every sentence adds value: purpose, threats detected, cost, and usage recommendation. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, cost, and usage context. However, it does not differentiate from sibling tools like scan_contract and deep_scan, which may be confusing for an agent selecting among them. It also lacks information about the payment flow (e.g., how to provide payment or what happens if omitted) and expected return value, relying on the schema for some of this. Given the presence of closely related siblings, the description is not fully complete.
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%, with each parameter (chain, payment, contract) clearly described. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
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 states a specific verb ('Verify') and resource ('smart contract') with a clear purpose ('for security risks before transacting'). It also lists concrete threat types detected (honeypots, rug pulls, high taxes, hidden ownership). However, it does not differentiate from sibling tools like scan_contract or deep_scan, which likely perform similar contract security checks.
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 a clear usage directive: 'Always call this before approving any on-chain transaction.' This provides strong contextual guidance. However, it does not explicitly mention when not to use this tool or name alternatives (e.g., deep_scan for more thorough analysis), so it lacks exclusions and alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context: registration action, plan requirement, and the types of contract changes triggering alerts. However, it omits operational details like idempotency, response format, webhook lifecycle, or duplicate handling, which limits transparency.
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 a single, front-loaded sentence with a clear verb and resource. Every word earns its place; there is no fluff or redundancy.
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?
Despite the lack of an output schema and annotations, the description adequately covers the core purpose and prerequisite for a registration tool. The schema enriches parameter understanding. It could mention the response or webhook lifecycle, but the description is sufficiently complete for basic usage.
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 input schema covers 80% of parameters with descriptions, meeting the high-coverage baseline of 3. The description adds context tying events to contract changes and the plan requirement to api_key, but it does not provide syntax or format details beyond the schema's own descriptions.
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 clearly states the verb 'Register' with the resource 'webhook' and specifies the exact purpose: receiving alerts for contract ownership, proxy, or risk changes. This differentiates it from sibling tools like monitor_wallet or scan_contract by focusing on webhook-based notifications.
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?
The description implies a use case (setting up proactive contract change alerts) but does not explicitly compare with alternatives like get_alerts or monitor_wallet. The plan requirement (Pro/Builder) is mentioned as a prerequisite, but there is no when-to-use vs. when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the auth requirement (paid subscription) and ticket multiplier behavior, which adds useful context. However, it does not describe side effects (e.g., creating an entry, idempotency, or what happens on repeated calls) or the response format, leaving important behavioral aspects unclear.
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 concise and well-structured: it opens with the action, then states the critical eligibility constraint, and finally explains ticket multipliers. Every sentence contributes useful information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the core action and constraints, but lacks details about what the caller can expect after entering (e.g., confirmation, ticket count, errors). It also does not clarify optional behavior related to agent_name or whether repeated entries are allowed, leaving some contextual gaps.
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 coverage is 100%, and both parameters (api_key and agent_name) have descriptions. The tool description does not add parameter-specific meaning beyond the schema; it only mentions plan-based ticket multipliers, which is related to eligibility rather than parameter semantics. The baseline of 3 applies because the schema fully documents parameters.
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 clearly states the action ('Enter the active giveaway') with a specific verb and resource. It distinguishes this tool from siblings like get_giveaway by focusing on entering rather than viewing, and adds a scope ('active giveaway') that defines the target.
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 provides explicit eligibility context ('PAID SUBSCRIBERS ONLY') and explains how ticket counts scale by plan, which helps the agent determine when this tool is appropriate. However, it does not explicitly mention alternative tools (e.g., get_giveaway for viewing) or exclusion scenarios beyond non-paid status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('View') and states that everyone competes, but it does not explicitly confirm safety, mention output format, or address potential rate limits. This is acceptable for a simple view but leaves some gaps in transparency.
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?
The description is concise and front-loaded with the primary purpose in the first sentence. The second sentence adds filter details and motivational context. While the prize information is not strictly technical, it helps clarify the competitive nature without being verbose. Overall, it wastes no words.
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?
For a simple tool with two optional parameters and no output schema, the description covers the core functionality (view leaderboard, filter by category, optional API key for rank). However, it does not describe the return structure (e.g., list of agents with rankings), which would be useful since there is no output schema. Still, it is sufficiently complete for the tool's simplicity.
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 both parameters (api_key and category) are fully documented. The description adds 'Filter by category' and lists the category values, but these already appear in the schema. It does not provide additional meaning beyond what the schema already conveys, earning the baseline score of 3.
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 clearly states the tool's purpose with a specific verb+resource: 'View the competitive agent leaderboard.' It distinguishes itself from sibling tools like get_stats or get_dashboard by focusing on rankings and competition. The additional context about prizes and categories makes the purpose unambiguous.
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 provides clear context on when to use the tool (to view leaderboard and compete for prizes) and how to filter by category. However, it does not explicitly exclude alternatives or name siblings, so it stops short of full when/when-not guidance. The context is sufficient for most agents to select this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 a key behavioral consequence (both parties get +500 free API calls). However, it doesn't mention any limits, idempotency, or what happens if a referral code already exists. This is adequate for a simple create action but lacks deeper safety or side-effect context.
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 a single, direct sentence that immediately states the action and the incentive. No filler or redundant content. It earns its place and is front-loaded with the primary purpose.
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?
The tool is simple (1 parameter, no output schema), and the description captures the essential outcome. It doesn't explain return values, but with no output schema that is less critical. The incentive and action are clear, making it sufficiently complete for the task.
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 input schema covers 100% of the single parameter 'api_key' with its description. The description adds no extra meaning beyond what the schema provides, matching the baseline for high schema coverage.
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 clearly states the action ('Create a referral code') and the resource (referral code). It also distinguishes itself from the sibling tool 'redeem_referral' by focusing on creation. The added incentive details ('+500 free API calls') provide context without ambiguity.
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 implies usage: call this when you want to create a referral code. While it doesn't explicitly mention alternatives or exclusions, the context is clear and naturally distinguishes from 'redeem_referral'. No explicit 'when not to use' is given, but the simple operation doesn't require it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys read-only intent via 'View' and adds a relevant restriction (paid subscribers only), but does not detail response format, authentication requirements, or whether past winners are publicly visible. This is an average disclosure for a simple read tool.
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 two concise sentences, front-loaded with the primary verb and resource. Every word earns its place; the paid-subscriber note adds useful context without bloat. This is appropriately sized for a simple tool.
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?
For a zero-parameter, read-only view tool with no output schema, the description adequately covers what is displayed (active giveaway, prizes, past winners) and an important limitation (paid subscribers only). It lacks explicit output format details but the simplicity of the tool and the presence of a sibling like enter_giveaway mitigate the need. Overall, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which yields a baseline of 4. Schema coverage is trivially 100%, and the description adds no parameter-related semantics because none exist. The baseline of 4 is appropriate given the absence of a parameter surface.
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 uses a specific verb ('View') and clearly identifies the resource ('active giveaway, prizes, and past winners'), making the tool's purpose unmistakable. It also differentiates from the sibling 'enter_giveaway' which involves participation, whereas this is purely a view operation.
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?
The description implies usage for checking giveaway-related information, but provides no explicit guidance on when to use this tool versus alternatives. The note that prizes are for paid subscribers only hints at eligibility context but does not compare with siblings like get_leaderboard or get_stats, leaving usage context vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the reward (+50 API calls) and the auto-flag threshold, but omits details about report reversibility, visibility, or whether the action modifies community state beyond the flag. This adds some context but leaves gaps.
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?
Two succinct sentences, front-loaded with the tool's main action, reward, and threshold. No filler or redundancy.
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?
For a report tool with a well-described schema and no output schema, the description covers the core purpose, incentive, and outcome threshold. It does not explain post-report response or edge cases, but is sufficiently complete given the tool's simplicity.
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 80%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides; parameters remain adequately documented by the schema.
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 uses a specific verb+resource ('Report a malicious contract to the community') that clearly identifies the action and target, distinguishing it from sibling tools like scan_contract or verify_contract. It also adds relevant purpose (community reporting) and consequence (auto-flag).
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 implies the intended use case (reporting malicious contracts) and includes contextual incentives and thresholds, but does not explicitly state when to use this versus alternatives like verify_contract or deep_scan. It offers clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals the scope of checks and performance (14+ checks in under 2 seconds), but does not disclose output format, error behavior, rate limits, or whether the scan is read-only. More behavioral detail would be useful.
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 two concise sentences, front-loading the core purpose and key differentiators. Every word earns its place with no redundancy or filler.
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?
For a tool with only two known parameters and no output schema, the description covers the primary use case, the nature of checks, and performance expectations. It lacks detail on output interpretation or edge cases, but the essentials are present.
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 coverage is 100% with both parameters described in the input schema. The description adds context about the tool's purpose but no additional parameter-level semantics beyond what the schema already provides. Baseline 3 is appropriate.
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 clearly states a specific action ('Full threat detection scan') and enumerates concrete checks (honeypots, rug pulls, mint authority, etc.), distinguishing it from siblings like verify_contract and deep_scan. The verb and resource are unambiguous.
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 explicitly says 'Use this before trading any token,' providing clear context for when the tool should be invoked. It does not explicitly name alternatives or exclusions, but the usage guidance is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the API key requirement and parallel execution, adding some context. However, it omits details about response structure, error handling, and whether the operation is read-only, leaving gaps for a tool with no annotations.
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 two sentences, front-loaded with purpose and limit, followed by requirements and behavior. Every sentence is informative with no fluff or redundancy.
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?
There is no output schema, so the description must explain return values, which it does ('returns safety verdict for each contract'). It covers the key aspects of a batch verification tool, though it lacks details on error handling and verdict format, leaving room for improvement.
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 coverage is 100%, so the baseline is 3. The description reinforces the 50-contract limit already stated in the schema and the API key requirement, but it adds no new parameter-specific meaning beyond what the schema describes.
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 clearly states the tool's function: to verify contracts in batch, up to 50 at a time. It uses a specific verb ('Verify') with a resource ('contracts') and highlights the batch aspect, distinguishing it from the sibling verify_contract tool.
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 implies usage when multiple contracts need verification ('up to 50 at once'), which provides clear context. It does not explicitly mention alternatives or when not to use it, but the batch context makes the intended use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 the specific analysis scope, the subscription-based rate limit (2 free/day), and implies a more intensive operation than sibling scans. It does not explicitly state read-only behavior, but 'analysis' implies no state mutation. Sufficiently transparent given the absence of annotations.
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 exactly two sentences, with the first sentence front-loading the core purpose and the second providing comparative and access information. Every word earns its place, with no filler or redundancy.
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?
The description covers purpose, comparative positioning, rate limits, and core analysis areas. While there is no output schema, the mention of 'risk breakdown' hints at the return type. For a tool with two parameters and clear scope, this is reasonably complete, though it could explicitly state whether the operation is read-only.
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%, with both `chain` and `contract` fully documented in the input schema. The description adds no additional parameter-level semantics, so the baseline of 3 applies as the schema does the heavy lifting.
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 opens with 'Deep forensic analysis:' followed by a specific list of analysis dimensions (ownership, permissions, exploit pattern matching, bytecode analysis, risk breakdown). It clearly identifies the tool's function and differentiates it from siblings by stating 'Goes deeper than verify or scan.' This is a specific verb+resource+scope that distinguishes it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Goes deeper than verify or scan' explicitly positions this tool relative to sibling tools, indicating when to use it over lighter-weight alternatives. The mention of '2 free/day, unlimited for Pro/Builder subscribers' also provides clear usage context and access constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key behavioral effect ('Stops all transaction signing until manually unfrozen'), the reversible nature, and an authorization requirement ('Requires API key (X-Agent-Key) or wallet ownership'). It does not detail side effects or error behavior, but covers the critical aspects.
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?
Two sentences, front-loaded with the action verb, and every word contributes. It packs the purpose, effect, duration, and auth requirement without fluff. No unnecessary repetition of schema fields.
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?
Given no output schema and no annotations, the description provides sufficient context for an emergency action: what it does, what it stops, how it is undone, and who can do it. It does not mention return values or success/failure indication, but for a freeze action the critical information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying that 'wallet' and 'agent_id' are alternative selectors ('for a wallet address or agent') and that 'api_key' is required for authorization. This goes beyond the individual schema descriptions.
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 clearly states a specific action: 'Emergency freeze all monitored wallets' with scope 'for a wallet address or agent.' This uses a distinct verb ('freeze') and resource ('monitored wallets') that immediately distinguishes it from read-only siblings like get_alerts or verify_contract.
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 word 'Emergency' establishes the intended context (use during threats/compromise), and 'Stops all transaction signing' explains the consequence. It does not explicitly name alternatives or exclusions, but no competing freeze tool exists among the siblings, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: monitoring, alerting via callback URL, and auto-freezing linked wallets. This goes beyond basic expectations by specifying the 'single transaction' trigger, making side effects transparent.
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?
Two sentences, front-loaded with the core purpose, then details. Every word adds value; no fluff or repetition of schema.
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?
The description covers the core monitoring behavior, trigger, and side effects. While there is no output schema or mention of return values, the tool is primarily a setup action, and the provided context is sufficient for an agent to use it correctly. Minor gap: no mention of idempotency or how to stop monitoring, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 meaningful semantics by clarifying that the alert triggers on a single-transaction drop, which is not explicit in the threshold_pct description. This helps the agent understand the exact condition.
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 clearly states the tool's function: 'Watch a wallet for drain threats' with specific behavior (alert and auto-freeze). It distinguishes itself from sibling tools like freeze_wallet and scan_contract by focusing on monitoring and reactive actions.
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 implies usage for ongoing monitoring of a wallet's balance, with clear trigger conditions (threshold drop in a single transaction) and consequences (alert and freeze). It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to know when to deploy this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![agentshield-mcp MCP server](https://glama.ai/mcp/servers/atmflow55/agentshield-mcp/badges/card.svg)](https://glama.ai/mcp/servers/atmflow55/agentshield-mcp)

Score Badge

Copy to your README.md:

[![agentshield-mcp MCP server](https://glama.ai/mcp/servers/atmflow55/agentshield-mcp/badges/score.svg)](https://glama.ai/mcp/servers/atmflow55/agentshield-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/atmflow55/agentshield-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server