foundrynet-inference
Server Details
x402 LLM proxy + data-enriched analysis (17 sources) + TimesFM predictive IoT intelligence.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 2.8/5 across 4 of 4 tools scored.
Each tool targets a distinct inference capability: analyze is network-wide data-enriched analysis with LLM, chat is a pure LLM proxy, infer handles IoT telemetry normalization and anomaly detection, and predict focuses on TimesFM-based threshold-breach forecasting. There is no overlap in functionality.
All tool names are single, imperative verbs (analyze, chat, infer, predict), following a uniform and predictable pattern. No mixing of conventions or styles.
With 4 tools, the server is tightly scoped for an inference-focused service. Each tool covers a clear sub-domain without being too few or too many for the stated purpose.
The tools cover the main inference modalities (LLM, IoT, predictive) and include a combined analysis tool. Minor gaps exist (e.g., no tool for listing available models or retrieving raw telemetry), but the core inference workflows are well supported.
Available Tools
4 toolsanalyzeCInspect
Data-enriched analysis across the FoundryNet network (17 sources) + LLM. $0.25/call.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| query | Yes | What to analyze, e.g. 'Analyze NVDA risk profile'. | |
| api_key | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially compensates by disclosing the cost ($0.25/call) and the data sources (17 sources + LLM). However, it does not disclose behavioral traits such as whether the tool performs read or write operations, requires authentication details, or has rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a single sentence that includes key information (analysis type, sources, cost). It is front-loaded and efficient, though it could be slightly more descriptive without losing brevity.
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 description is incomplete given the tool's complexity (3 parameters, no output schema, no annotations). It fails to specify the output format, parameter usage details, or context for when to invoke this tool versus siblings, leaving significant gaps for an AI agent.
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 33% of parameters have descriptions in the schema (query). The description adds no parameter information beyond what is already in the schema, failing to explain the purpose of 'model' or 'api_key' parameters. Given the low schema coverage, the description should compensate but does not.
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 performs 'Data-enriched analysis across the FoundryNet network (17 sources) + LLM', indicating a specific verb (analyze) and resource. However, it does not differentiate from sibling tools like 'chat' or 'infer', lacking clear distinction.
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 no guidance on when to use this tool versus alternatives. It only describes what the tool does, without any context on appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chatCInspect
LLM inference proxy (Claude). $0.02/call.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| prompt | No | Single user prompt (shortcut for messages). | |
| system | No | ||
| api_key | No | fnet_ Forge key to bypass payment. | |
| messages | No | Anthropic-format messages array. | |
| max_tokens | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions cost but does not disclose safety, side effects, rate limits, or whether it is read-only or destructive.
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?
Very concise at one sentence, but omits essential details. Could be restructured to add more value without losing brevity.
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 6 parameters, no output schema, and no annotations, the description is insufficient. Missing information on return format, usage patterns, and behavioral constraints.
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 50% with some parameter descriptions already present. The description adds no new parameter-level detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'LLM inference proxy (Claude)' which gives a general idea but lacks a specific verb+resource. It does not distinguish from sibling tools like analyze, infer, predict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inferCInspect
IoT telemetry inference — normalize + forecast + anomaly flags. $0.10/call.
| Name | Required | Description | Default |
|---|---|---|---|
| oem | No | ||
| api_key | No | ||
| telemetry | Yes | { field: value | [series] } sensor readings. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must fully convey behavioral traits. It mentions core operations (normalize, forecast, anomaly) and cost but omits side effects, idempotency, rate limits, or safety profile. The tool appears to be a read-like inference but this is not confirmed.
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 sentence with cost is concise but lacks structure; key information like output or usage is absent. Every word is functional, but the description is too brief to be fully helpful.
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?
Despite a nested object parameter and no output schema, the description fails to explain response format, parameter interactions (e.g., api_key use), or required vs optional fields. The tool's complexity demands more detail than provided.
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 one of three parameters (telemetry) has a schema description (33% coverage). The tool description adds no further semantic detail about parameters like oem or api_key, nor how they affect behavior. The telemetry object is described vaguely as sensor readings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool performs IoT telemetry inference including normalization, forecasting, and anomaly flags. It distinguishes the tool's purpose from siblings like 'analyze' or 'predict' but does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (analyze, chat, predict). No information about prerequisites or contexts where the tool is inappropriate. Only pricing is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predictCInspect
TimesFM predictive intelligence — threshold-breach forecast + recommendation + MINT attestation. $0.10/call.
| Name | Required | Description | Default |
|---|---|---|---|
| oem | No | OEM hint for normalization. | |
| values | Yes | Historical canonical values, oldest→newest (≥16 recommended). | |
| api_key | No | ||
| direction | No | 'above' or 'below'. | |
| threshold | Yes | Value to test for a crossing. | |
| canonical_field | No | FCS field, e.g. 'spindle_load_pct'. |
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 full burden. It mentions a cost of $0.10/call, but does not disclose whether the tool is read-only, modifies state, requires authentication, or has rate limits. The term 'attestation' suggests some recording, but this is unclear.
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 (one sentence plus cost) and front-loaded with the key capability. However, it could be slightly more structured (e.g., separating function from cost).
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 has 6 parameters, no output schema, and the description omits details about return values, interpretation of recommendation/attestation, and example usage. This leaves gaps for an AI agent to correctly invoke the 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 description coverage is 83%, so the schema already documents 5 of 6 parameters. The description adds the context 'TimesFM predictive intelligence' but does not elaborate on parameter usage or format beyond what is in the schema. 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?
The description clearly states the tool performs threshold-breach forecast, recommendation, and MINT attestation using TimesFM. It specifies the verb 'predict' and resource (time-series data), but does not explicitly differentiate from siblings 'analyze', 'chat', and 'infer'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (analyze, chat, infer). No exclusions or prerequisites are mentioned.
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!