TweetFeed
Server Details
IOCs (URLs, domains, IPs, hashes) shared by the infosec community on X/Twitter. No auth, CC0.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- 0xDanielLopez/tweetfeed-mcp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 8 of 10 tools scored.
Each tool has a clearly distinct purpose: hash, IP, URL checks are separate; enrich_ioc provides comprehensive lookup; get_campaigns, get_tag_info, get_trending, get_trends, list_recent_iocs, and query_iocs each serve unique functions with no overlap.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_hash, enrich_ioc, get_trending, list_recent_iocs), making the API predictable and easy to navigate.
10 tools is well-scoped for a threat intelligence server, covering lookups, enrichment, campaign analysis, trends, delta sync, and queries without being excessive.
The tool set covers the full lifecycle of IOC interaction: single-type checks, enriched lookup, campaign grouping, tag analysis, trending statistics, delta listing, and flexible queries. No obvious gaps for the stated domain.
Available Tools
10 toolscheck_hashAInspect
Check whether a file hash (MD5 or SHA-256) appears in the TweetFeed corpus over the past 30 days. Useful for confirming if a binary sample has been shared by the public infosec Twitter/X community. Hash type auto-detected from length (32 hex = MD5, 64 hex = SHA-256). Exact match on hex value, case-insensitive.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | MD5 (32 hex chars) or SHA-256 (64 hex chars) hash. Case-insensitive. Non-hex characters or wrong length will return an INVALID_PARAMS error. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses auto-detection of hash type and error handling (INVALID_PARAMS) for invalid input. However, does not mention failure modes for missing hashes, rate limits, or return format.
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, efficient and front-loaded with the core purpose. Every sentence provides essential information without redundancy.
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 one-parameter tool with no output schema, the description covers purpose, usage context, parameter details, and input validation. Missing return value format, but overall sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds valuable detail: auto-detection logic, case-insensitivity, and explicit error on invalid input. Goes beyond baseline 3 by clarifying edge cases.
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 ('Check') and resource ('file hash in TweetFeed corpus'), clearly distinguishing from sibling tools like 'check_ip' and 'check_url'.
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?
States usefulness for confirming if a binary sample has been shared by the infosec community, providing context. Lacks explicit exclusions or alternative tool names for when not to use, but the sibling list makes differentiation clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_ipAInspect
Check whether an IP address appears in the TweetFeed corpus over the past 30 days. Useful for confirming if an observed IP has been flagged as attacker infrastructure (C2, scanner, phishing host) by the public infosec Twitter/X community. Substring match against the 'value' field of type=ip IOCs (so '1.2.3' will also match '1.2.3.4'). Pass a full IPv4 / IPv6 string for an exact-match feel.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IPv4 or IPv6 address to search (e.g. '185.107.56.42', '2a02:...'). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description fully covers behavioral traits: discloses substring matching (e.g., '1.2.3' matches '1.2.3.4'), data source (TweetFeed), and timeframe (30 days). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded main action. Every sentence adds value: first does purpose, second adds usage guidance and behavioral note. No waste.
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 purpose, usage, behavioral nuance. Lacks description of return values (no output schema), but tool is simple and context is adequate for agent invocation.
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?
Only parameter 'ip' has 100% schema coverage, and description adds examples and clarifies substring behavior not in schema, adding meaningful value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'check', resource 'IP address in TweetFeed corpus', and timeframe. Differentiates from siblings like check_hash and check_url by specifying the data source and substring matching behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Useful for confirming if an observed IP has been flagged as attacker infrastructure...' providing clear context. No explicit alternatives or when-not-to-use, but reasonable given sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_urlAInspect
Check whether a URL (or substring) appears in the TweetFeed corpus over the past 30 days. Useful for confirming if an observed URL has been flagged by the public infosec Twitter/X community. Case-insensitive substring match against the 'value' field of type=url IOCs. Returns matching rows with date, researcher handle, value, tags, and source tweet URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL or URL substring to search (e.g. 'fake-bank.com/login', 'phish-domain.tld'). Case-insensitive. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the 30-day time window, case-insensitive substring match, and return fields (date, researcher handle, value, tags, source tweet URL). No destructive effects or auth needs are expected. It adds context beyond the schema.
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 four sentences, each adding value. It is front-loaded with the main purpose and efficient in conveying all necessary 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 single parameter, no output schema, and no annotations, the description is fairly complete. It explains what the tool does, the input, the output fields, and the context (30-day window). It could mention alternative tools for other IOC types, but that is implied by siblings.
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 a detailed parameter description including examples and case-insensitivity note. The description adds no new parameter information beyond the schema, so baseline score of 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 checks if a URL appears in the TweetFeed corpus over the past 30 days, using case-insensitive substring matching. It specifies the action (check), resource (URL in TweetFeed), and distinguishes from siblings like check_hash and check_ip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Useful for confirming if an observed URL has been flagged by the public infosec Twitter/X community', which implies when to use. While it does not explicitly mention when not to use or list alternatives, the sibling context provides differentiation. A more explicit guidance would raise the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
enrich_iocAInspect
Look up an IOC value in TweetFeed. First an EXACT lookup over the past 365 days (aggregated: first_seen, last_seen, count, reporters, tags, last source tweets; accepts defanged input and http/https variants), including AI-generated context (summary, malware family, threat type) when available. If no exact match, falls back to a 30-day substring scan with auto-detected type (URL / domain / IP / MD5 / SHA-256).
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | IOC value to look up. Type is auto-detected: 32 hex chars = MD5, 64 hex chars = SHA-256, dotted-quad = IPv4, label.tld = domain, anything containing '://' or '/' = URL. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but the description covers key behaviors: exact vs substring search, aggregation fields, defanged input handling, AI context, and type detection. Missing rate limits or auth, but sufficient for typical usage.
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 with dense information. Could be slightly more concise by merging clauses, but all content is relevant and front-loaded.
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?
With no output schema, the description lists output fields (first_seen, last_seen, count, reporters, tags, etc.) and AI context. Sufficient for a single-parameter tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with auto-detection details already in schema description. Description adds defanged input handling and http/https variants, adding value beyond 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?
Clear verb 'Look up' and specific resource 'IOC value in TweetFeed'. Distinguished from sibling tools like check_hash, check_ip, check_url by describing a combined exact+fallback lookup with AI context, which is unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes the two-stage lookup (exact then fallback) and type auto-detection, providing context for when this tool handles multiple IOC types. Not explicit about when to prefer siblings, but the behavior is well explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_campaignsAInspect
AI-clustered campaign groupings of the last 7 days of community-shared TweetFeed IOCs: each campaign bundles related URLs/domains/IPs/hashes under a name, a short context summary, a clustering confidence (high/medium/low), and a targeted brand when one was identified, plus a sample of member IOCs. Regenerated daily from a rolling 7-day window. Useful for 'what phishing campaigns are active right now' or 'is this IOC part of a larger campaign' queries. Optional filters narrow by targeted brand or minimum confidence.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Optional: filter by targeted brand, case-insensitive substring match against targeted_brand (e.g. 'paypal', 'microsoft'). Campaigns with no identified brand are excluded when this is set. | |
| limit | No | Optional: max campaigns to return (1-50). Default 20. | |
| min_confidence | No | Optional: minimum clustering confidence to include (low < medium < high). Only campaigns at or above this confidence are returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data source (TweetFeed IOCs), time window (last 7 days, rolling), regeneration frequency (daily), and output components (name, summary, confidence, brand, sample IOCs). No annotations exist, so description carries full burden; it does not mention authentication or rate limits, but as a read-only operation this is acceptable.
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?
Description is well-structured: starts with output contents, then data window and regeneration, then use cases, then filters. Every sentence adds value. Could be slightly more concise, but overall 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?
Adequately describes output structure for a tool without output schema, covering all key fields. Mentions optional filters and their effects. No obvious gaps given moderate complexity and good schema.
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 description adds minimal value beyond schema. It reiterates that filters narrow by brand or confidence but does not provide additional syntax or formatting details. Baseline of 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?
Specifies verb and resource: retrieves AI-clustered campaign groupings of recent IOCs. Clearly distinguishes from sibling tools focused on single IOC lookups (check_hash, check_ip, check_url) and list tools (list_recent_iocs, get_trending).
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 states two use cases: 'what phishing campaigns are active right now' and 'is this IOC part of a larger campaign'. Does not explicitly state when not to use, but the contrast with single-IOC siblings is implied. Guidance on optional filters is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tag_infoInspect
Bundle of TweetFeed activity for a single tag: aggregate counts across today/week/month/year windows plus the most recent IOCs. Saves the agent from making three separate calls to assemble a tag overview. Tag can be passed with or without a leading '#'.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag to look up (e.g. 'phishing', 'CobaltStrike', 'lockbit'). Case-insensitive. The leading '#' is optional. ~122 tags exist - see https://tweetfeed.live/tags/ for the full list. | |
| limit | No | Max recent IOCs to include (1-100). Default 10. |
get_trendingAInspect
Top tags and IOC-type distribution for a given time window, computed from the live counts.json aggregate. Useful for 'what is the infosec community talking about right now' or 'which malware family is spiking this week' queries. Source: https://raw.githubusercontent.com/0xDanielLopez/TweetFeed/master/counts.json (regenerated every 15 min).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many top tags to return (1-100). Default 20. | |
| window | Yes | Time window. 'today' = since UTC midnight, 'week' = last 7 days, 'month' = last 30 days, 'year' = last 365 days. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the data source, update frequency (every 15 min), and that results are computed from a live aggregate. However, it does not explain what 'top tags' or 'IOC-type distribution' specifically includes, nor any limitations.
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 succinct: two sentences defining purpose and use cases, plus a source/update line. No extraneous content, and important information is front-loaded.
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 two-parameter tool with no output schema, the description gives adequate context: what the tool returns, how it works, freshness, and example queries. Missing details like response format are not critical given the tool's simplicity.
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 covers both parameters (limit, window) with descriptions. The additional description does not add semantic value beyond what the schema provides. With 100% schema coverage, 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 it provides 'top tags and IOC-type distribution for a given time window', specifying the verb ('get' is implied) and resource ('trending' aggregates). It distinguishes from sibling tools by focusing on aggregate trends rather than specific IOC lookups or enrichments.
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 includes two explicit use-case queries ('what is the infosec community talking about right now', 'which malware family is spiking this week'), which guide when to use. It does not explicitly exclude other uses, but given sibling tools, 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.
get_trendsAInspect
IOC trend analytics from the last 31 days: daily volume by type, top moving tags week-over-week, most-abused TLDs, and new vs recurring indicator ratio.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Optional: which section to return. 'daily' = 31-day volume summary by type, 'movers' = top tags moving week-over-week (current 7d vs previous 7d), 'tlds' = most-abused TLDs among domain IOCs, 'novelty' = new vs recurring indicator ratio, 'all' = every section. Default 'all'. | all |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden. It transparently describes the time range (last 31 days) and the specific analytics computed. It does not mention any destructive behavior or authentication needs, which is acceptable for a read-only analytics 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?
The description is a single efficient sentence that conveys all essential information without waste. It is front-loaded and covers the core functionality.
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 single-parameter schema and no output schema, the description sufficiently explains the return content. However, it lacks details about output format or error cases, but these are not critical for a straightforward analytics tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a well-documented 'section' parameter. The description adds minimal extra meaning beyond the schema; it summarizes the output but does not elaborate on parameter usage. 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 purpose: providing IOC trend analytics over the last 31 days. It lists specific sections (daily volume, top movers, TLDs, novelty ratio), which distinguishes it from sibling tools like 'get_trending' and 'query_iocs'.
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 the tool is for trend analytics but does not explicitly state when to use it versus alternatives such as 'get_trending' or 'query_iocs'. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_recent_iocsInspect
List TweetFeed IOCs added since a given date, useful for delta-syncing a blocklist or Threat Intelligence pipeline. Source is the 30-day month window so 'since' must be within the past 30 days; older queries return only the part within the month window. Optional 'type' and 'tag' filters narrow the result. Sorted newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Optional: filter by tag (case-insensitive substring match on the tag list). | |
| type | No | Optional: filter by IOC type. | |
| limit | No | Max results (1-1000). Default 100. | |
| since | Yes | ISO date (YYYY-MM-DD) for the lower bound. Example: '2026-04-15'. |
query_iocsAInspect
Query the TweetFeed API for Indicators of Compromise (IOCs: URLs, domains, IPs, MD5/SHA256 hashes) shared by the infosec community on Twitter/X. Returns matching rows with date, researcher handle, type, value, tags, and tweet URL. All data CC0 licensed. The 'year' time window is not supported here (too large for a tool response) - use the /v1/year HTTP redirect directly if you need it.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Optional: filter by tag, case-insensitive substring match. Examples: 'phishing', 'cobaltstrike', 'ransomware', 'APT', 'Lockbit'. ~122 tags exist - see https://tweetfeed.live/ for the live taxonomy. | |
| time | Yes | Time window. 'today' = since UTC midnight, 'week' = last 7 days, 'month' = last 30 days. | |
| type | No | Optional: filter by IOC type. | |
| user | No | Optional: filter by Twitter/X handle WITHOUT the @ prefix (e.g. 'malwrhunterteam', 'JCyberSec_'). | |
| limit | No | Optional: max rows to return (1-1000). Default 100. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses key behaviors: returns rows with specific fields, CC0 licensed, and the unsupported 'year' window. It lacks mention of rate limits, authentication needs, or pagination, but is generally transparent for a read query 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?
The description is concise (4 sentences), front-loaded with the primary purpose, and each sentence contributes essential information: function, output, licensing, and a limitation/alternative. No redundancy.
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 5-parameter query tool without output schema, the description covers purpose, output fields, and a key limitation. It could elaborate on pagination or default ordering, but overall it provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds value beyond schema by noting the 'year' time window is unsupported and suggesting an alternative, which enriches understanding of the 'time' parameter.
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 queries the TweetFeed API for IOCs (URLs, domains, IPs, hashes) and lists returned fields. It distinguishes from sibling tools by specifying the scope (querying a feed rather than checking specific indicators) and explicitly mentions limitations like the unsupported 'year' window.
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 provides context on when to use this tool (for querying IOCs with time filters) and explicitly states that the 'year' window is not supported, directing users to an alternative via HTTP redirect. However, it does not explicitly compare with sibling tools like check_hash or enrich_ioc.
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!