Urlhaus
Server Details
URLhaus MCP — wraps abuse.ch URLhaus malware URL database (free, no auth)
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- pipeworx-io/mcp-urlhaus
- 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.1/5 across 10 of 10 tools scored.
Many tools serve the Pipeworx platform (ask, discover, remember, etc.) rather than the URLhaus malware database, creating ambiguity. An agent may struggle to distinguish between URLhaus-specific lookups and auxiliary memory/tool-discovery functions.
Naming patterns are mixed: some use verb_noun (lookup_host, resolve_entity), while others are single words or phrases (forget, recall, ask_pipeworx). No consistent convention is followed.
Ten tools is a reasonable count, but the set includes many tools unrelated to the server's stated domain (URLhaus). The effective URLhaus subset is only 4 tools, making the overall count feel padded.
The URLhaus-specific tools cover only lookup and recent listings, missing crucial operations like URL submission, statistics, or tag-based search. The Pipeworx tools do not fill these gaps, leaving the surface incomplete.
Available Tools
12 toolsask_pipeworxAInspect
Ask a question in plain English and get an answer from the best available data source. Pipeworx picks the right tool, fills the arguments, and returns the result. No need to browse tools or learn schemas — just describe what you need. Examples: "What is the US trade deficit with China?", "Look up adverse events for ozempic", "Get Apple's latest 10-K filing".
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your question or request in natural language |
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 states the tool picks the right tool and fills arguments, indicating automated action. However, it does not disclose potential side effects, rate limits, or what happens if the question cannot be answered.
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 three sentences: first defines the action, second explains the process, third gives examples. No unnecessary 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 tool's simplicity (one required parameter, no output schema, no nested objects), the description is nearly complete. It explains input, process, and provides examples. Missing details about output format or error handling are minor.
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% for a single parameter, and the description adds value by explaining how the question parameter is used (natural language, examples provided). This goes beyond the schema's generic 'Your question or request in natural language'.
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 takes a natural language question and returns an answer from the best data source, using other tools as needed. It distinguishes itself from sibling tools by acting as a central query interface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: 'No need to browse tools or learn schemas — just describe what you need.' It provides examples of appropriate questions, implying this is the primary tool for answering queries without specifying alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_entitiesAInspect
Compare 2–5 entities side by side in one call. type="company": revenue, net income, cash, long-term debt from SEC EDGAR. type="drug": adverse-event report count, FDA approval count, active trial count. Returns paired data + pipeworx:// resource URIs. Replaces 8–15 sequential agent calls.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type: "company" or "drug". | |
| values | Yes | For company: 2–5 tickers/CIKs (e.g., ["AAPL","MSFT"]). For drug: 2–5 names (e.g., ["ozempic","mounjaro"]). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions data sources (SEC EDGAR, FDA) and output format (paired data + URIs). No annotations provided, so description carries full burden. Lacks details on auth, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with clear front-loading of purpose. No wasted words; effectively uses colon structure for type-specific details.
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 simple parameter structure and no output schema, description fully covers purpose, parameter semantics, and output behavior. Agent can confidently decide to use and fill parameters.
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 covers 100% of parameters. Description adds meaning with examples for 'values' and specifies returned data per enum value for 'type', going beyond schema definitions.
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 'Compare 2–5 entities side by side' with specific types (company/drug) and data fields. Distinguishes from siblings like lookup_host/lookup_payload by noting it replaces 8–15 sequential calls.
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 describes when to use (side-by-side comparison, replacing sequential calls) and provides input constraints (2-5 entities, type choices). Does not state exclusions, but context of siblings implies when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_toolsAInspect
Search the Pipeworx tool catalog by describing what you need. Returns the most relevant tools with names and descriptions. Call this FIRST when you have 500+ tools available and need to find the right ones for your task.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tools to return (default 20, max 50) | |
| query | Yes | Natural language description of what you want to do (e.g., "analyze housing market trends", "look up FDA drug approvals", "find trade data between countries") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it returns 'names and descriptions' of relevant tools, which is useful behavioral context. Since no annotations are provided, the description carries the burden; it does well by stating the function clearly, though it could add info about performance or 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 two sentences with no wasted words. It front-loads the core action and then provides context. Slightly more structure could help, but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, no nested objects), the description is complete enough. It explains the tool's role in the workflow and the query format. Minor gap: no mention of whether results are ranked or how relevance works, but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the 'query' parameter should be a natural language description and gives examples, and notes defaults/max for 'limit'. This goes beyond the schema's terse descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to search the tool catalog by describing what you need, and returns the most relevant tools. It distinguishes itself from siblings by emphasizing discovery of tools when there are 500+ available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task,' giving clear when-to-use guidance and implying it is a preliminary step before using other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetAInspect
Delete a stored memory by key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key to delete |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states 'Delete a stored memory by key' which implies a destructive action, but it does not clarify irreversibility, whether the operation is idempotent, or what happens if the key does not exist. More detail would be beneficial.
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 sentence with no wasted words. It is concise and front-loaded with the action. Could be slightly more structured but adequate.
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?
The tool is simple with one required parameter, and the description covers the core purpose. However, without annotations or behavioral details (e.g., idempotency, error handling), it feels slightly incomplete for a destructive operation. Output schema is absent, but for a delete operation, the return value might be trivial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'key' parameter. The description adds no additional meaning beyond 'by key', which is already clear from the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('stored memory by key'), clearly distinguishing it from sibling tools like 'remember' (store) and 'recall' (retrieve).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when a specific memory needs to be permanently removed. It does not explicitly state when not to use or mention alternatives, but the verb 'delete' makes the intent clear. Sibling names like 'remember' and 'recall' provide contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recentAInspect
Get a list of recently submitted malware URLs from URLhaus. Useful for monitoring the latest threats.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recent URLs to return (default 10, max 1000). |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Total number of earthquakes in response |
| earthquakes | Yes | List of recent earthquakes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly indicates a read-only operation and mentions the source (URLhaus). It could add more details about ordering, but the description is sufficient given the simple nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the main purpose and then provide context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple parameters, no output schema, and a straightforward purpose, the description is nearly complete. Could optionally mention return format or default behavior, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter (limit) fully described in schema. Description adds no extra meaning beyond schema, so 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 verb 'Get' and resource 'list of recently submitted malware URLs from URLhaus', with a specific use case 'monitoring the latest threats'. It is distinct from siblings which focus on lookups, discovery, or memory operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for monitoring latest threats but does not explicitly state when to use this tool versus siblings like lookup_url or search tools. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_hostAInspect
Look up a hostname or IP address in the URLhaus database to find associated malware URLs. Returns all known malicious URLs hosted on that host.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Hostname or IP address to look up (e.g. "example.com" or "192.168.1.1"). |
Output Schema
| Name | Required | Description |
|---|---|---|
| urls | Yes | List of malware URLs on this host |
| url_count | Yes | Number of malware URLs found on this host |
| blacklists | Yes | Blacklist detection status by various services |
| query_status | Yes | Status of the query |
| urlhaus_reference | Yes | Reference URL on URLhaus for this host |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses that it returns 'all known malicious URLs hosted on that host', which implies read-only behavior. However, no info on rate limits, data freshness, or whether it modifies anything. Adequate but could add more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second clarifies what is returned. Efficient and front-loaded. Slight redundancy between 'malware URLs' and 'malicious URLs' but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter and no output schema, description is mostly complete for a lookup tool. However, no mention of result format or pagination, which might be needed for many results. Adequate but not outstanding.
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 good description for the host parameter. Description adds no additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Look up', specific resource 'hostname or IP address in the URLhaus database', and outcome 'find associated malware URLs'. Distinguishes from siblings like lookup_url and lookup_payload by specifying host-level lookup and malware URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for looking up hosts to find malware URLs, but does not explicitly state when to use vs alternatives (e.g., lookup_url, lookup_payload). No when-not-to-use or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_payloadAInspect
Look up a malware payload file by its MD5 or SHA256 hash in the URLhaus database. Returns file type, size, first/last seen dates, and associated delivery URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| md5_hash | No | MD5 hash of the payload to look up (32 hex characters). | |
| sha256_hash | No | SHA256 hash of the payload to look up (64 hex characters). |
Output Schema
| Name | Required | Description |
|---|---|---|
| md5_hash | Yes | MD5 hash of the payload |
| file_type | Yes | File type of the payload |
| last_seen | Yes | Date when payload was last seen |
| signature | Yes | Malware signature name if available |
| url_count | Yes | Number of URLs serving this payload |
| first_seen | Yes | Date when payload was first seen |
| sha256_hash | Yes | SHA256 hash of the payload |
| query_status | Yes | Status of the query |
| delivery_urls | Yes | URLs associated with this payload delivery |
| file_size_bytes | Yes | Size of the payload file in bytes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates the tool is a read-only query, but since annotations are empty, it does not explicitly state no side effects. It lists returned data, which adds value, but no info on rate limits or error handling.
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?
Single concise sentence providing essential information. Could be slightly improved by separating the returned fields for readability, 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?
Given no output schema and simple parameters, the description covers the purpose, input, and output well. Missing information about possible error states or empty results, but overall sufficient for a lookup 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%, so the schema already documents both parameters with descriptions. The description adds context about MD5 and SHA256 usage, but does not clarify which parameter is preferred or if both can be used together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Look up', the resource 'malware payload file', and the method 'by its MD5 or SHA256 hash'. Also specifies the database 'URLhaus' and lists returned fields, distinguishing it from siblings like lookup_host and lookup_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?
Implies that the tool is for looking up known hashes, but no explicit guidance on when to use this versus other lookup tools, or what to do if the hash is not found.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_urlAInspect
Look up a URL in the URLhaus malware database to check if it is known to host or distribute malware. Returns threat category, status, blacklist status, and tags.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The full URL to look up (e.g. "http://example.com/malware.exe"). |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | URLhaus ID for this URL |
| tags | Yes | Associated tags for the URL |
| threat | Yes | Threat category (e.g. 'malware', 'phishing') |
| blacklists | Yes | Blacklist detection status by various services |
| date_added | Yes | Date when URL was added to database |
| url_status | Yes | Status of the URL (e.g. 'online', 'offline') |
| query_status | Yes | Status of the query (e.g. 'ok', 'no_results') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool is a lookup/read operation (not destructive), and mentions the return includes threat category, status, blacklist status, and tags. This adequately informs the agent of the tool's behavior.
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 sentence that efficiently conveys the tool's purpose and the type of information returned. No unnecessary words. Front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, no output schema, and no annotations, the description is reasonably complete. It covers the purpose, the input, and the output fields. It could mention that the output format is not specified, but the description lists the types of information returned, which is sufficient for an agent to decide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'url' parameter. The description adds context that the URL should be a full URL (e.g., example), which is helpful but does not go beyond the schema's description. Thus, 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's purpose: to look up a URL in the URLhaus malware database. It specifies the action ('Look up'), the resource ('URL in the URLhaus malware database'), and the goal ('check if it is known to host or distribute malware'). This distinguishes it from sibling tools like lookup_host and lookup_payload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no guidance on when to use it versus alternatives. For example, it doesn't mention that this tool is specifically for URLs (as opposed to hosts or payloads), which could be inferred from sibling names but is not explicit. No when-not-to-use or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pipeworx_feedbackAInspect
Send feedback to the Pipeworx team. Use for bug reports, feature requests, missing data, or praise. Describe what you tried in terms of Pipeworx tools/data — do not include the end-user's prompt verbatim. Rate-limited to 5 messages per identifier per day. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | bug = something broke or returned wrong data. feature = a new tool or capability you wish existed. data_gap = data Pipeworx does not currently expose. praise = positive note. other = anything else. | |
| context | No | Optional structured context: which tool, pack, or vertical this relates to. | |
| message | Yes | Your feedback in plain text. Be specific (which tool, what error, what data was missing). 1-2 sentences typical, 2000 chars max. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the tool's purpose, rate limit (5 per identifier per day), and the kind of content expected (describe Pipeworx tools/data). Without annotations, the description provides sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences with no redundancy. The most critical information (purpose, usage guidelines, rate limit) is front-loaded and efficiently communicated.
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 feedback tool with no output schema, the description covers purpose, usage, parameters (via schema), rate limit, and content guidelines, leaving no major gaps.
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 all parameters with descriptions, so baseline is 3. Description adds value by clarifying the style of feedback (describe tools/data, no verbatim prompts) and the rate limit, enhancing understanding 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?
The description clearly states the verb 'Send feedback' and the resource 'Pipeworx team', and specifies distinct use cases (bug reports, feature requests, missing data, praise), making it unambiguous and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (feedback) and what not to include (end-user prompt verbatim), plus mentions rate limit. Does not contrast with siblings, but their functions are clearly different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallAInspect
Retrieve a previously stored memory by key, or list all stored memories (omit key). Use this to retrieve context you saved earlier in the session or in previous sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Memory key to retrieve (omit to list all keys) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the two modes (retrieve by key, list all) and states it retrieves context saved in current or previous sessions. Does not cover edge cases (e.g., missing key), but sufficient for basic use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, no wasted words. Concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional parameter, no output schema, no nested objects), the description is complete. It covers both retrieval and listing modes. Could mention return format but not critical.
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 one parameter 'key' described in schema. Description adds the behavior of omitting key to list all, which is a useful nuance beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves a memory by key or lists all if key omitted. The verb 'retrieve' and resource 'memory' are specific, and the listing behavior distinguishes it from siblings like forget or remember.
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?
Description says when to use (retrieve context saved earlier) and implies alternative (omit key to list all). No explicit when-not-to-use or comparison with siblings, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberAInspect
Store a key-value pair in your session memory. Use this to save intermediate findings, user preferences, or context across tool calls. Authenticated users get persistent memory; anonymous sessions last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key (e.g., "subject_property", "target_ticker", "user_preference") | |
| value | Yes | Value to store (any text — findings, addresses, preferences, notes) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description bears full responsibility for behavioral transparency. It discloses that the tool stores data, explains the persistence difference between authenticated and anonymous sessions, and implies it is a write operation. It could mention if overwriting an existing key is allowed or if there are size limits.
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 extremely concise at two sentences, with all critical information front-loaded. Every sentence adds value: the first states the core action and storage location, the second provides use cases and persistence details. No redundant 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 tool has only two simple parameters with full schema coverage, no output schema, and no nested objects, the description is quite complete. It covers purpose, use cases, and persistence behavior. A minor gap is not mentioning whether the tool overwrites existing keys or if there are size constraints on key or value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both parameters. The description adds context about the types of values to store (findings, addresses, preferences) and example keys, which goes beyond the schema. This adds meaningful guidance for the agent on how to use the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stores a key-value pair in session memory and distinguishes it from siblings like recall (which likely retrieves) and forget (which likely deletes). It specifies the purpose as saving intermediate findings, user preferences, or context across tool calls.
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 (to save findings, preferences, or context across calls) and includes details about memory persistence (persistent for authenticated users, 24-hour for anonymous). However, it does not explicitly mention when not to use it or alternative tools like forget or recall for other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_entityAInspect
Resolve an entity to canonical IDs across Pipeworx data sources in a single call. Supports type="company" (ticker/CIK/name → SEC EDGAR identity) and type="drug" (brand or generic name → RxCUI + ingredient + brand). Returns IDs and pipeworx:// resource URIs for stable citation. Replaces 2–3 lookup calls.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type: "company" or "drug". | |
| value | Yes | For company: ticker (AAPL), CIK (0000320193), or name. For drug: brand or generic name (e.g., "ozempic", "metformin"). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description fully shoulders transparency. Discloses v1 limitation to type='company' and return fields (ticker, CIK, name, URIs). Missing error handling or edge cases.
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, zero wasted words. First sentence defines purpose, second adds operational details. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description fully specifies return fields. With 2 parameters and clear usage examples, the description equips the agent with all needed information for correct 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?
Schema already describes both parameters (type enum, value string). Description adds critical context: type only supports 'company', value can be ticker/CIK/name with concrete examples and v1 scope.
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 'resolve', resource 'entity', and specific outcome 'canonical IDs across Pipeworx data sources'. Distinguishes from siblings by noting it replaces multiple lookup calls.
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?
Provides explicit input examples (ticker, CIK, name) and explains efficiency gain. Lacks explicit when-not-to-use or alternative tools, but context implies it's the go-to for entity resolution.
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!