pfc-mcp

by yusong652

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: browsing vs searching documentation, synchronous vs asynchronous code execution, and task lifecycle management. No overlaps even among similar-looking pairs like browse_commands/query_command.
Naming Consistency5/5
All tools follow a consistent pfc_verb_noun pattern with underscores. Verbs like browse, query, execute, check, interrupt, list are used uniformly, and nouns are appropriately singular or plural.
Tool Count5/5
10 tools is well-scoped for a simulation environment server, covering documentation browsing/searching, task submission/management, and code execution without redundancy.
Completeness4/5
The set covers documentation browsing/searching for both commands and Python API, plus full task lifecycle management. The only minor gap is a dedicated simulation state query tool, but that is achievable via pfc_execute_code.
Average 4.2/5 across 10 of 10 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 116 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
View related servers

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

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 only adds 'graceful' to indicate cooperative shutdown but does not disclose side effects (e.g., whether it can be called multiple times, if it blocks, or error behavior). The description adds minimal transparency 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is front-loaded but minimal. It is concise but could benefit from slightly more detail without becoming verbose.
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?
Although the tool is simple (one parameter, output schema exists), the description lacks context about when the task must be running or the outcome if already stopped. The output schema exists, so return description is not required, but usage context is missing.
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 100% (task_id is described as 'Task ID returned by pfc_execute_task'). The tool description adds no further parameter guidance. Baseline of 3 is appropriate since the schema already documents the parameter sufficiently.
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 identifies the action ('request graceful interruption') and the resource ('running PFC task'). It distinguishes itself from sibling tools like pfc_execute_task (which starts tasks) and pfc_check_task_status (which checks status). However, the term 'graceful' is ambiguous and not elaborated upon.
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 gives no guidance on when to use this tool versus alternatives, no prerequisites (e.g., task must be running), no exclusions (e.g., cannot interrupt completed tasks), and no mention of expected preconditions. The usage context is implied but not explicit.
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. It mentions pagination but does not explain behavioral details like ordering, impact on tasks (read-only?), or how to navigate pages. The schema's skip_newest parameter hints at chronological order but is not explained.
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 sentence with no wasted words. However, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full schema coverage, the description is adequate but could be improved by clarifying ordering or scope (e.g., lists all tracked tasks ordered by creation time).
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 coverage is 100%, setting baseline at 3. The description adds only the generic term 'pagination' which loosely relates to limit/skip parameters but does not explain their specific semantics (e.g., skip_newest skips most recent tasks).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 the resource 'tracked PFC tasks' with the qualifier 'with pagination'. This distinguishes it from siblings like pfc_check_task_status (status checking) and pfc_execute_task (execution).
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 pfc_check_task_status or pfc_execute_task. The description lacks any context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'Browse ... by path (like glob + cat)' which implies read-only behavior (browsing documentation). However, it lacks explicit disclosure of traits like error behavior, rate limits, or whether it modifies state. The behavioral insight is adequate but minimal.
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?
Single sentence with effective analogy, clearly front-loaded. No superfluous content. However, the description could be slightly more informative without sacrificing length (e.g., mentioning it returns structured docs). Still, very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter with exhaustive schema examples and presence of an output schema (which covers return values), the description is sufficient for a browse tool. The analogy provides context for expected behavior. Minor gap: no mention of error handling or recursion depth, but not critical.
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 coverage is 100% and includes detailed examples for the api parameter. The description adds no additional parameter information beyond what the schema provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it browses PFC Python SDK documentation by path, using the analogy 'like glob + cat' which clearly indicates listing and reading. It distinguishes from siblings like pfc_browse_commands (commands) and pfc_browse_reference (reference) by specifying 'Python API' and hierarchical path navigation.
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?
No explicit when-to-use or alternatives mentioned. The analogy 'like glob + cat' and the detailed path examples in the schema imply usage for navigating hierarchical documentation, but no comparison to siblings like pfc_query_python_api or pfc_browse_commands is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently describes the output as 'combined Python prints and PFC console output interleaved in execution order' and explains pagination and filtering behavior. It lacks discussion of error handling or rate limits but is generally sufficient.
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 two sentences with no waste. The first sentence states the purpose, and the second adds key behavioral details. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and an output schema, the description covers the main usage and output structure well. It does not detail edge cases (e.g., task not found) but is complete for normal operation.
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?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that skip_newest/limit control pagination, filter selects matching lines, and wait_seconds sets a delay before querying. This goes beyond the schema's bare descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check status and paginated output' and the resource 'submitted PFC task'. It distinguishes from siblings like pfc_execute_task (submits) and pfc_interrupt_task (interrupts) by focusing on status checking and output retrieval.
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?
The description explains pagination and filtering mechanics but does not explicitly state when to use this tool versus alternatives (e.g., after submitting a task). The context is implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. It states the return type (matching API paths with signatures) but does not disclose any other behavioral traits like pagination, case-insensitivity (though in schema), or side effects. For a read-only search, it is minimally adequate but not rich.
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 concise, front-loaded with the core purpose, followed by return info and usage guidelines. Every sentence is useful and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (return values not needed in description), two well-documented parameters, and clear related tools, the description is complete for a simple search tool.
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 100%, so baseline is 3. The description adds overall context and examples but does not significantly enhance parameter understanding beyond the schema descriptions, which already provide examples and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches PFC Python SDK documentation by keywords, returning matching API paths with signatures. It distinguishes itself from siblings like pfc_browse_python_api (for known paths) and pfc_query_command (for commands), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to use' guidance: when you have keywords but don't know the exact API path, with examples. It also lists related tools with their purposes, giving clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavior. It explains the three navigation levels and the version parameter, implying read-only browsing. However, it does not explicitly state that no modifications are made or that results are text documentation, which is important for transparency.
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?
Concise and well-structured with bullet points for navigation levels and when-to-use. No redundant sentences; every line adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and the tool's simple purpose, the description covers all necessary aspects: purpose, usage guidelines, parameter details, and related tools. It is fully self-contained.
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 100% with examples. The description adds context like 'space-separated, matching PFC syntax' and the three navigation levels, but these are already implied in the schema examples. Baseline 3 is correct as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses PFC command documentation by path, with specific navigation levels (all categories, category only, full command). It distinguishes from siblings like pfc_query_command and pfc_browse_reference by purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section tells the agent to use this when the command category or exact command is known, and lists alternatives for other cases (pfc_query_command for keyword search, pfc_browse_reference for reference docs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It explains that the tool returns matching command paths and accepts search keywords. While it doesn't explicitly state read-only or safety, the functionality implies a safe search operation. The description adds value by mentioning case-insensitivity and version support.
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 concise and well-structured. It starts with the core functionality, then provides usage guidelines, examples, and related tools. Every sentence adds value without redundancy. The structure is front-loaded with the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but confirmed), the description is complete. It covers the tool's purpose, parameters, usage recommendations, and links to sibling tools. No critical information is missing for effective tool selection and invocation.
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?
Schema coverage is 100% with each parameter documented. The description adds extra context beyond the schema, such as examples for the query parameter, explanation that results are matching command paths, and default version mention. This enhances the agent's understanding of parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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: 'Search PFC command documentation by keywords (like grep)'. It specifies the action (search), resource (command documentation), and method (by keywords). It also differentiates from the sibling tool pfc_browse_commands, which is for full documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides 'When to use' guidance, stating to use this tool when keywords are known but exact command path is unknown, with examples. It also lists related tools and their distinct purposes, offering clear guidance on alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses synchronous blocking, main thread execution, side effects persistence, interleaving with tasks, timeout limits, and non-cancellability. No annotations present, so tool carries full disclosure burden.
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?
Well-structured with sections, front-loaded with core purpose. Slightly verbose with environment details and extensive typical uses, but information is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive given no annotations: covers behavioral traits, environment, typical uses, error conditions (timeout), and distinction from other tools. No gaps for agent decision-making.
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?
Schema covers both parameters with descriptions. Description adds context (code runs in main thread, timeout defaults/max) but schema already provides sufficient meaning. High schema coverage reduces need for extra description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it executes Python code synchronously in PFC. Differentiates from pfc_execute_task (synchronous vs. background) and other sibling tools like pfc_query_command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists typical uses (REPL, inspection, tuning) and warnings (do not use for .dat files, prefer pfc_execute_task for cancellable work). Provides clear when-to-use and 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses async behavior, immediate task_id return, background execution, pollable/cancellable nature, ability to modify state during execution via pfc_execute_code, namespace sharing, console output interleaving, and timeout resolution. No annotations exist, so burden is fully on description.
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?
Front-loaded with primary action, then logically structured with lifecycle details, sync alternative, warnings, and troubleshooting. Every sentence adds information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of async task submission with lifecycle management, the description covers all necessary aspects: async behavior, sibling tools, namespace sharing, console output, .dat file warning, timeout handling, and references to external resources. Output schema existence (task_id) is noted.
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?
Schema described 100% of parameters. Description adds context (absolute path, workspace) for entry_script, and purpose for description. While schema already has descriptions, the description integrates parameter usage into the async execution flow, providing added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Submit a Python script file for asynchronous execution in PFC' and differentiates from sibling pfc_execute_code by specifying sync vs async paths. It also contrasts with pfc_check_task_status, pfc_interrupt_task, pfc_list_tasks for lifecycle management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (async/background) and when not (use pfc_execute_code for sync), provides alternatives for .dat file execution, and warns against blocking practices. Troubleshooting steps for timeouts are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains navigation levels (no topic, category, full path), how the version parameter filters contact models, and that range-elements and plot-items are version-agnostic. This provides essential behavioral context beyond basic read operation.
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 well-structured with clear sections: main purpose, navigation levels, when-to-use list, and related tools. It is front-loaded with the core purpose and uses bullet points for readability. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-level navigation, version filtering, multiple use cases) and the presence of an output schema, the description is complete. It covers all necessary information for an agent to understand when and how to use the tool, including examples and version behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant meaning beyond the schema: it explains the navigation structure with concrete examples for the topic parameter and clarifies how version filters contact models while noting version-agnostic topics. This enhances usability for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it browses PFC reference documentation for syntax elements and model properties, and distinguishes from siblings by specifying that references are language elements used within commands, not standalone commands. It also lists related tools with their purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use this tool (e.g., need contact model property names, range filtering syntax, plot item configuration) and mentions related tools (pfc_browse_commands for command syntax, pfc_query_command for keyword search), providing clear guidance on tool selection.
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:

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

Score Badge

Copy to your README.md:

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

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/yusong652/itasca-mcp'

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