Skip to main content
Glama

DATA/AGENT FOUNDRY

by io.github.Reztek-creator
OverviewDiscussionsAdmin

Server Details

Free catalogue; paid historical software/security evidence. No current-risk assessment.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-06-18
URL

TDQS

B3.4/5.0

Scored across 4 tools

Disambiguation4/5

The purchase and purchase-read tools are clearly distinguished as write/payment versus read/recover operations. The main potential overlap is between foundry_products' historical task/evidence discovery and foundry_selectors' discovery of held historical request parameters, but the descriptions provide enough context to separate catalogue inspection from selector-level parameter discovery.

Naming Consistency3/5

All tools consistently use the foundry_ prefix and snake_case, which keeps them readable as a set. However, the names mix resource-noun patterns (foundry_products, foundry_selectors) with verb/action patterns (foundry_purchase, foundry_purchase_read), so there is no single predictable verb_noun convention.

Tool Count5/5

Four tools is well-scoped for a focused product discovery, selection, purchase, and purchase-retrieval workflow. Each tool covers a distinct stage and there are no obviously redundant tools padding the surface.

Completeness4/5

The buyer-facing lifecycle is mostly covered: discovery, selector inspection, purchasing, and reading an existing purchase. Minor gaps could exist around quotes, purchase status/listing management, or post-purchase operations, but the core advertised workflow is complete enough for agents to operate.

Available Tools

4 tools
foundry_productsAInspect

Free public discovery. Use {"view":"tasks","task":"exact_historical_evidence","subject":"postgresql"} to choose by historical task and held output, or {"view":"summary","limit":64} for the short offer index. Read {"product_id":""} alone for the public contract before advertised selectors or a quote. Omitting view/product_id preserves the full catalogue, default3 and limit1..64/next_cursor. Zero task cards is not zero vulnerabilities; a summary or schema enum is not MATCH or current applicability.

NameRequiredDescriptionDefault
taskNo
viewNo
limitNo
cursorNo
subjectNo
product_idNo

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden and does add useful context: free public discovery, default limit, cursor pagination, product_id-only reads, and cautions that zero task cards is not zero vulnerabilities. However, it does not clearly state return format, authentication/rate-limit behavior, or explicitly declare read-only semantics.

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 dense but front-loaded with the core discovery purpose and examples, and the caveats at the end are meaningful. It could be clearer structurally, but there is little wasted text.

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 tool with six optional parameters, complex allOf constraints, no annotations, and no output schema, the description covers the main usage modes and important caveats. It remains incomplete because it does not explain return values or fully document the enum and constraint semantics an agent would need for confident invocation.

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 0%, so the description must compensate. It partially does by explaining view modes, product_id-only usage, limit defaults/ranges, cursor continuation, and examples for task and subject, but it does not explain all task enum values or all combination constraints encoded in the schema.

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 frames the tool as free public product discovery and uses examples to show catalogue, summary, task, and single-product contract retrieval. The purpose is clear from the modes and examples, though it does not explicitly name sibling tools or state a clean verb+resource phrase like 'list products'.

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?

It gives concrete mode-selection guidance: tasks view for historical task/output, summary view for the offer index, product_id alone for the public contract, and omitted selectors for the full catalogue. It also positions the tool before selectors or a quote, but does not explicitly name sibling alternatives or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

foundry_purchaseBInspect

Buy a configured public product by product_id and its exact business body. Generic clients receive a payment challenge; paying requires an external authorized client.

NameRequiredDescriptionDefault
bodyYes
product_idYes

TDQS

B3.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose genuinely non-obvious behavior: the call initiates a purchase that returns a payment challenge rather than completing payment, and settlement requires an external authorized client. It still omits what happens to the challenge, whether retries are safe, and any permission/rate-limit constraints.

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?

Two short sentences with the core action and the payment caveat front-loaded; every clause carries information. The 'generic clients' phrasing is slightly opaque but not wasteful.

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 two-parameter mutation with no annotations, no output schema, and an entirely undocumented free-form body, the description leaves real gaps: how to construct the body and what a challenged response means for next steps. It covers the high-level flow but not enough to call the tool confidently.

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 description coverage is 0% and 'body' is an unconstrained nested object, so the description must compensate. 'Its exact business body' hints that the object must be complete (matching additionalProperties: false) but never explains what fields belong in body, how to obtain them from foundry_products, or what product_id refers to beyond the name.

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 gives a concrete verb and resource ('Buy a configured public product') and names both required inputs, which is enough to distinguish it from the read-only siblings. It doesn't explicitly contrast with foundry_purchase_read, so an agent must infer the difference from the name alone.

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?

'Generic clients receive a payment challenge; paying requires an external authorized client' implies that this tool alone cannot complete a purchase for an ordinary caller, which is useful routing information. However, it never states the alternative path (e.g. use foundry_purchase_read or delegate to an authorized client) or the prerequisite for calling it successfully.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

foundry_purchase_readBInspect

Read/recover this exact original purchase through existing HTTP READ authentication. Never signs or settles. Supply cursor for an existing result page.

NameRequiredDescriptionDefault
cursorNo
authorization_idYes
original_requestYes

TDQS

B3.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description does carry real weight: it declares the operation is read-only over HTTP READ auth with no signing or settlement side effects, and discloses pagination via cursor. It does not disclose behavior on a missing/expired authorization, whether the operation is idempotent, or what is returned, leaving meaningful gaps for a zero-annotation tool.

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?

Three short sentences, no filler, with the safety constraint ('never signs or settles') placed early. The only cost is that the terse phrasing 'this exact original purchase' trades clarity for brevity.

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?

For a tool with no annotations, no output schema, 0% parameter coverage and a nested free-form object, the description is too thin. It omits what 'recover' actually yields, what original_request must contain, and how authorization_id relates to the purchase, so an agent cannot confidently construct a call.

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 description coverage is 0%, so the description must explain all three parameters, yet it only addresses cursor ('for an existing result page'). authorization_id and the nested original_request object are entirely unexplained — an agent cannot tell whether original_request must be the exact prior call payload or something else.

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?

States a specific verb pair (read/recover) and the resource (the original purchase), and the phrase 'Never signs or settles' implicitly contrasts it with the mutating foundry_purchase sibling. However, 'this exact original purchase' is referentially vague — the object being read is only pinned down by the schema's authorization_id.

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?

Says cursor is supplied 'for an existing result page', which implies continued pagination rather than a first call, and 'never signs or settles' steers agents away from using this to execute a purchase. But no sibling is named as the alternative for signing/settling, and no prerequisites (must the purchase already exist?) are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

foundry_selectorsBInspect

Discover exact held historical request parameters for a currently configured listed product. Free, no payment or purchased evidence; use next_cursor and exact filters. Currentness remains UNKNOWN.

NameRequiredDescriptionDefault
limitNo
cursorNo
filtersNo
product_idYes

TDQS

B3.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the full burden. It discloses that the tool is free, that currentness is unknown, and that pagination uses a cursor. However, it omits error handling, authentication needs, rate limits, and the exact return format or behavior on invalid input.

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 generally front-loaded, starting with the core purpose. The additional clauses are relevant, though the abrupt 'Currentness remains UNKNOWN' feels tacked on rather than smoothly integrated.

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?

Given four parameters including a nested filters object, no output schema, and no annotations, the description is severely incomplete. It should explain the return type, how to use filters, what 'selectors' means, and the significance of product_id. Key details for correct invocation are missing.

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 description coverage is 0%, so the description must explain the parameters. It only vaguely references 'next_cursor' (schema uses 'cursor') and 'exact filters' without detailing what each filter does, the purpose of 'limit', or the required 'product_id'. Most parameter semantics are left undefined.

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 ('Discover') and resource ('exact held historical request parameters') for a 'currently configured listed product'. It implicitly distinguishes from paid alternatives by saying 'Free, no payment or purchased evidence', but it does not name or contrast with sibling tools like foundry_products or foundry_purchase_read.

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?

It provides a usage hint ('use next_cursor and exact filters') and mentions the tool is free, implying it is an alternative to paid services. However, it does not explicitly state when to use this tool versus its siblings, nor does it specify when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedfoundry_products4 fields changed
      • changedInput schema / allOf
        Previous value: -[
-  {
-    "not": {
-      "required": [
-        "product_id",
-        "view"
-      ]
-    }
-  },
-  {
-    "not": {
-      "required": [
-        "product_id",
-        "limit"
-      ]
-    }
-  },
-  {
-    "not": {
-      "required": [
-        "product_id",
-        "cursor"
-      ]
-    }
-  },
-  {
-    "if": {
-      "not": {
-        "required": [
-          "product_id"
-        ]
-      }
-    },
-    "then": {
-      "properties": {
-        "limit": {
-          "default": 3
-        }
-      }
-    }
-  }
-]New value: +[
+  {
+    "not": {
+      "required": [
+        "product_id",
+        "view"
+      ]
+    }
+  },
+  {
+    "not": {
+      "required": [
+        "product_id",
+        "limit"
+      ]
+    }
+  },
+  {
+    "not": {
+      "required": [
+        "product_id",
+        "cursor"
+      ]
+    }
+  },
+  {
+    "not": {
+      "required": [
+        "product_id",
+        "task"
+      ]
+    }
+  },
+  {
+    "not": {
+      "required": [
+        "product_id",
+        "subject"
+      ]
+    }
+  },
+  {
+    "if": {
+      "not": {
+        "required": [
+          "product_id"
+        ]
+      }
+    },
+    "then": {
+      "properties": {
+        "limit": {
+          "default": 3
+        }
+      }
+    }
+  },
+  {
+    "if": {
+      "required": [
+        "task"
+      ]
+    },
+    "then": {
+      "properties": {
+        "view": {
+          "const": "tasks"
+        }
+      },
+      "required": [
+        "view"
+      ]
+    }
+  },
+  {
+    "if": {
+      "required": [
+        "subject"
+      ]
+    },
+    "then": {
+      "properties": {
+        "view": {
+          "const": "tasks"
+        }
+      },
+      "required": [
+        "view"
+      ]
+    }
+  }
+]
      • addedInput schema / properties / subject
        Added value: +{
+  "enum": [
+    "apache_httpd",
+    "cert_fr",
+    "cisa_kev",
+    "cpython",
+    "go",
+    "multi_source_cve",
+    "postgresql"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / task
        Added value: +{
+  "enum": [
+    "correction_group_dossier",
+    "declared_version_conditions",
+    "exact_historical_evidence",
+    "historical_comparison",
+    "historical_support_end"
+  ],
+  "type": "string"
+}
      • changedInput schema / properties / view / enum
        Previous value: -[
-  "summary"
-]New value: +[
+  "summary",
+  "tasks"
+]
  2. 1 tool update
    • Changedfoundry_products4 fields changed
      • addedInput schema / allOf
        Added value: +[
+  {
+    "not": {
+      "required": [
+        "product_id",
+        "view"
+      ]
+    }
+  },
+  {
+    "not": {
+      "required": [
+        "product_id",
+        "limit"
+      ]
+    }
+  },
+  {
+    "not": {
+      "required": [
+        "product_id",
+        "cursor"
+      ]
+    }
+  },
+  {
+    "if": {
+      "not": {
+        "required": [
+          "product_id"
+        ]
+      }
+    },
+    "then": {
+      "properties": {
+        "limit": {
+          "default": 3
+        }
+      }
+    }
+  }
+]
      • removedInput schema / properties / limit / default
        Removed value: -3
      • addedInput schema / properties / product_id
        Added value: +{
+  "maxLength": 160,
+  "minLength": 1,
+  "type": "string"
+}
      • addedInput schema / properties / view
        Added value: +{
+  "enum": [
+    "summary"
+  ],
+  "type": "string"
+}
  3. 4 tool updates
    • First observedfoundry_products
    • First observedfoundry_purchase
    • First observedfoundry_purchase_read
    • First observedfoundry_selectors

Related MCP Connectors

Related MCP Servers

  • websec-auditor

    sheiscypher
    F
    license
    Not graded
    quality
    B
    maintenance
    Passive website security and trust auditor that checks for security, SEO, AI surface, email, and other exposures, producing a score and remediation plan.
    -

  • Computer Expert

    Pawnnwap
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables read-only inspection and diagnosis of Windows, macOS, and Linux machines through eight diagnostic tools covering system profiles, baselines, disk health, startup audits, driver context, and upgrade planning, with voice summaries and a web simulator. It enforces an R0-R3 risk model in code so only safe R0 evidence collection is automatic while riskier actions remain manual guidance.
    MIT

  • MCP Security Tools Suite

    Ap6pack
    -
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables ethical security testing and attack surface management through SSL certificate validation, CVE queries, subdomain enumeration, security header analysis, and comprehensive reconnaissance capabilities. Designed for authorized penetration testing workflows with responsible disclosure practices.
    -
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources