Foundry MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap. execute_function runs code, list_functions enumerates functions, list_ontology_types lists types, query_dataset queries datasets, and query_ontology_type queries specific ontology types. The descriptions clearly differentiate their scopes and usage contexts.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case. The verbs (execute, list, query) are appropriately chosen for their actions, and the nouns (function, ontology_type, dataset) clearly indicate the target resources. No deviations or mixed conventions are present.
Tool Count5/5
With 5 tools, this server is well-scoped for its apparent domain of data and function management in a Foundry context. Each tool serves a distinct and necessary purpose, covering listing, querying, and execution operations without bloat or redundancy.
Completeness4/5
The toolset provides solid coverage for querying and listing operations on functions, datasets, and ontology types, with execute_function enabling action. A minor gap exists in update/delete operations for these resources, but agents can likely work with the provided read/execute capabilities for common workflows.
Average 2.8/5 across 5 of 5 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It doesn't indicate whether this is a read or write operation, what permissions are required, whether it's idempotent, what happens on failure, or any rate limits. 'Execute a function' could imply anything from a simple calculation to a destructive database operation with no safety information.
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 extremely concise - a single sentence with no wasted words. While this brevity contributes to efficiency, it comes at the cost of meaningful content. The structure is simple and front-loaded, but the content is insufficient for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (executing functions with parameters), lack of annotations, 0% schema coverage, no output schema, and presence of sibling tools, the description is completely inadequate. It provides no context about what system this operates in, what functions are available, what the execution entails, or how results are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters (including a nested object), the description provides no meaningful parameter semantics. It mentions 'given parameters' but doesn't explain what 'query_api_name' represents, what format 'parameters' should take, or provide any examples. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute a function using given parameters' is a tautology that essentially restates the tool name 'execute_function'. It doesn't specify what kind of functions, what system they're executed in, or what the execution entails. While it mentions 'using given parameters', this adds minimal clarification beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling tools (list_functions, list_ontology_types, query_dataset, query_ontology_type). There's no mention of prerequisites, appropriate contexts, or distinctions from alternatives. The agent receives no help in selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, how results are returned (e.g., pagination), or any rate limits. This leaves significant gaps for an agent to understand 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no wasted words. It's appropriately sized for a simple tool, though it could be slightly more informative without losing conciseness.
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 the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'ontology types' are, how they relate to other tools, or what the return values look like. For a tool with no structured context, more detail is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and a baseline score of 4 is appropriate for this case as it avoids misleading or redundant information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('List') and target ('ontology types'), but lacks specificity about what 'ontology types' are or how they differ from related resources. It doesn't distinguish from sibling tools like 'query_ontology_type', leaving the purpose somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'query_ontology_type' or other siblings. The description implies a simple listing operation but offers no context about prerequisites, typical 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the Spark SQL dialect and provides a query example, but doesn't address critical behavioral aspects like whether this is a read-only operation, what permissions are required, potential rate limits, query execution time, error handling, or what happens with large result sets. The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that efficiently communicates the core functionality with an example. Every word earns its place, and the structure is front-loaded with the essential information. There's no wasted verbiage or unnecessary elaboration.
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 that this is a query tool with no annotations, no output schema, and minimal parameter documentation, the description is incomplete. It doesn't address what the tool returns, how results are formatted, error conditions, performance characteristics, or integration with sibling tools. For a tool that executes potentially complex queries, more contextual information would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some semantic context by specifying that queries use 'Spark SQL dialect' and providing an example query format. However, with 0% schema description coverage for the single 'query' parameter, the description doesn't fully compensate by explaining parameter constraints, valid query patterns, or syntax requirements beyond the basic example. The baseline is 3 since there's only one parameter, but more detail would be helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Query a dataset') and specifies the method ('using Spark SQL dialect'), which provides a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from its sibling tools like 'query_ontology_type' or 'execute_function', which might have overlapping query capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to sibling tools like 'query_ontology_type' or 'execute_function', nor does it provide any context about prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it lists functions but doesn't disclose behavioral traits like whether it's read-only, paginated, rate-limited, or what format the output is in. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
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 the lack of annotations and output schema, the description is incomplete. It doesn't explain return values, behavioral constraints, or how it fits with siblings, leaving gaps in understanding for the agent despite the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for 0 parameters is 4, as the description doesn't need to compensate for any missing param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all available functions'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_ontology_types' or 'query_ontology_type', which might also list things, so it's not fully distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention context, prerequisites, or compare to siblings like 'execute_function' or 'query_dataset', leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description mentions querying objects but doesn't disclose key behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, or what happens on errors. For a query tool with zero annotation coverage, this is a significant gap, as it leaves the agent guessing about safety and operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, consisting of two concise sentences: the first states the purpose, and the second provides usage guidance. Every sentence earns its place by adding value without redundancy, making it efficient and easy to parse.
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?
Given the tool's complexity (querying ontology objects with two parameters), lack of annotations, and no output schema, the description is somewhat complete but has gaps. It covers the purpose and a prerequisite, but doesn't explain return values, error handling, or behavioral traits. This makes it adequate as a minimum viable description, but it could benefit from more details to fully guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning the input schema already documents both parameters ('where' and 'object_type') with descriptions. The description adds minimal value beyond this, only implying that 'object_type' relates to ontology types and referencing 'list_ontology_types' for available types. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Query for objects in a given ontology type.' It specifies the verb ('query') and resource ('objects in a given ontology type'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'query_dataset' or 'list_ontology_types', which keeps it from a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'Use list_ontology_types to get the list of available types.' This gives a prerequisite step, helping users understand when to use this tool. However, it doesn't specify when to use this tool versus alternatives like 'query_dataset' or 'execute_function', so it lacks explicit exclusions or comparisons, preventing a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/qwert666/mcp-server-foundry'

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