prosuite-mcp

Official

by ProSuite

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.2.2
Disambiguation4/5
Most tools have clearly distinct purposes: listing/describing conditions versus describing/searching/loading specs versus running verifications. However, run_verification and run_xml_verification both execute verifications and could be confused if an agent doesn't carefully read the parameter differences, and preview_condition_run partially overlaps with run_verification.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern: list_conditions, describe_condition, describe_spec, search_spec, load_spec, add_condition_to_spec, run_verification, preview_condition_run, run_xml_verification. The only slight outlier is preview_condition_run, but it still fits the pattern well.
Tool Count5/5
With 9 tools, the server is well-scoped for its purpose. Each tool addresses a distinct stage in the QA workflow—discovery, spec management, ad-hoc running, and XML-based running—without unnecessary bulk or gaps that would require extra tools.
Completeness4/5
The toolset covers the core lifecycle: listing conditions, describing them, loading/describing/searching specs, previewing condition additions, and running verifications (both ad-hoc and XML). The main gaps are the lack of a persistent save/update operation for specs (add_condition_to_spec only previews) and no tool for retrieving past verification results or reports.
Average 4.6/5 across 9 of 9 tools scored. Lowest: 4/5.
See the Tool Scores section below for per-tool breakdowns.
- 20 of 39 community issues answered or closed in the last 6 months
- 94 commits in the last 12 weeks
- Last stable release on August 6, 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.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns a docstring and parameter list with types, explains parameter types (dataset names must match, primitives take direct values), and notes that optional parameters get defaults. No mention of auth or rate limits, but appropriate for a describing tool. No contradiction.
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 front-loaded with the purpose and returns overview. It then adds relevant usage details about parameter interpretation for run_verification. While efficient, the extra details could be considered tangential, preventing a perfect 5.
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?
The tool has one input parameter and an output schema. The description covers what the tool returns (docstring, parameter list) and provides crucial context for using those parameters with run_verification. However, it omits an explicit definition of the 'name' parameter, leaving a minor gap in completeness.
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?
The sole input parameter 'name' (string required) is not explained in the description. Despite 0% schema description coverage, the description does not compensate for this parameter. It instead discusses parameters of the condition being described, which are not part of the input schema.
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 'Describe the parameters of a ProSuite quality condition' and mentions 'Returns the full docstring and parameter list with types.' This explicitly differentiates from siblings like list_conditions (lists conditions) and describe_spec (describes a spec).
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: it returns parameter information needed for run_verification, with details on how to interpret dataset vs primitive parameters and optional defaults. However, no explicit when-not-to-use or comparison with alternative tools, so not a 5.
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 must disclose behavior. It mentions that it describes the active spec and returns 'ok' or 'error', but does not explicitly state that it is a read-only operation or discuss potential errors beyond status. Adequate but could be more transparent.
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?
Concise description with purpose front-loaded. Four sentences efficiently convey purpose, usage context, and return status without extraneous detail.
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 zero parameters and no output schema, the description sufficiently covers the tool's role within the sibling set, especially its relationship to run_xml_verification. Lacks error details but is otherwise complete for its complexity.
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?
No parameters exist, so baseline 4. The description explains what the tool does without schema reliance, adding value by clarifying the scope of description (specifications, workspaces, datasets).
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: describing the loaded QA spec file, including available specifications, workspace definitions, and per-specification summary. This distinguishes it from siblings like list_conditions (individual conditions) and describe_condition (specific condition).
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?
Explicitly advises calling this before run_xml_verification to learn specification names, workspace IDs, and dataset names. It also clarifies which spec is described (active from load_spec or default path). Lacks explicit when-not-to-use or alternative tools, but the guidance is clear and actionable.
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 discloses that the tool runs from the loaded XML spec file, preserves per-condition dataset filters and defaults, and details the behavior of output_dir and spec active selection (last loaded or PROSUITE_SPEC_PATH). No contradictions.
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 an overview, differentiation, prerequisite guidance, and a clear 'Args' section. Efficient use of language without unnecessary words. Could be slightly more concise but overall effective.
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?
Covers purpose, behavior, usage, parameter meanings, and output summary. Given that an output schema exists (context indicates true), the description appropriately mentions the return format without over-specifying. Sufficient for a tool with complex parameters and nested objects.
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 0%, but the description explains all four parameters in detail, including examples for data_source_replacements and envelope format. Fully compensates for the missing schema 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?
Clearly states 'Run a ProSuite quality verification directly from the loaded XML spec file.' Differentiates from sibling tool run_verification by explaining that this tool sends the XML as-is without decomposing, preserving details like filters and defaults.
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?
Explicitly contrasts with run_verification, telling when to use this tool over the alternative. Provides a prerequisite hint: 'Use search_spec (with empty query) to discover available specification_name values and workspace_id keys.' Lacks explicit when-not-to-use or other sibling exclusions.
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 provided, the description carries full burden. It discloses that this runs the condition for real, returns engine-confirmed summary like run_verification, and describes output_dir behavior based on local vs server. This adds significant behavioral context beyond the schema.
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 front-loaded with purpose and guidelines, then uses a bulleted 'Args' section for parameters. While slightly verbose, every sentence adds value; the structure aids readability.
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 no annotations, 6 parameters, and an output schema (not shown), the description comprehensively covers purpose, usage, parameters, and return value (referencing run_verification output). It leaves minimal gaps for the agent to infer.
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 0%, so the description must compensate. It provides detailed explanations for all 6 parameters, including path examples, the structure of condition_request, envelope format, and output_dir behavior. This far exceeds minimal requirements.
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 runs a proposed condition ad-hoc and shows what it flags. It distinguishes itself from add_condition_to_spec (which only confirms build/descriptor) and run_verification (which runs full verification), establishing a unique purpose as a preview tool.
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 says this is 'Tier-2 confirmation for spec authoring' to be used after add_condition_to_spec, and contrasts with run_verification. It advises to scope envelope to keep it a preview, providing clear when-to-use and limitations.
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?
With no annotations, the description fully carries the transparency burden. It discloses critical behavior: it 'never synthesizes' a descriptor, 'never writes to a file', defaults spec_xml to the active spec or PROSUITE_SPEC_PATH, and returns structured status. It also warns that the name 'must not already exist' and that category is only needed for multi-category specs.
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 verbose for 9 parameters and a complex preview operation. It front-loads the core purpose in the first sentence, then organizes details into a clear Args block. No extraneous fluff; every sentence contributes 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 tool's complexity, no annotations, and the existence of an output schema, the description is complete. It explains return values, side-effect-free behavior, prerequisites, and parameter semantics. It even mentions how to persist the result ('ready to review and persist yourself'), fulfilling the contextual needs for safe invocation.
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 0%, but the Args section compensates entirely by adding semantic meaning to every parameter. For example, condition_request is explained as '{condition: method name from list_conditions, params: dict}', datasets are described as 'Feature classes/tables', and spec_xml's default behavior is fully specified. This exceeds what the schema alone provides.
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 opens with a specific verb and resource: 'Preview adding a new QualityCondition to a spec, reusing an existing descriptor.' It clearly distinguishes itself from siblings by stating it is 'Preview only: never writes to a file' and referencing run_verification for context, making the tool's scope unambiguous.
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 advises to 'Call describe_spec first for valid specification/workspace/dataset names' and clearly states this is a preview that returns XML for the user to persist. However, it stops short of explicitly naming alternative tools (like preview_condition_run or run_verification) and explaining when to use them instead.
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?
The description effectively communicates the read-only nature of listing conditions and the return format (names and descriptions). It could be slightly more explicit about being non-destructive, but the behavior is clear. No annotations exist, so the description carries the full burden adequately.
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?
Three concise sentences with no wasted words. The purpose is front-loaded, and follow-up actions are efficiently described.
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?
The description is complete given the tool's simplicity (1 optional parameter with default, no required fields, output schema exists). It provides enough context for an AI agent to correctly select and invoke the tool among siblings.
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?
The only parameter 'search' is explained in the description: it filters by keyword matched against name and description. This adds significant meaning beyond the schema name 'Search' alone, compensating for 0% schema description coverage.
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 lists available ProSuite quality conditions, providing condition names and one-line descriptions. It distinguishes from siblings like describe_condition which provides full parameter details, and run_verification for execution.
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 mentions using the search parameter to filter by keyword, and advises passing a result name to describe_condition for full details before building a run_verification call, guiding proper usage and tool chaining.
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 provided, the description carries the full burden. It discloses key behaviors: replaces any previously loaded spec, takes precedence over PROSUITE_SPEC_PATH, and returns status with conditions_loaded or error. It does not explicitly mention file access permissions or error handling details, but covers the essential behavioral traits.
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: first sentence states purpose, second paragraph explains side effects and precedence, third gives usage guidance, and then a clear bullet for the argument and return value. No redundant information.
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 simplicity (one param, no output schema, no annotations), the description is complete. It covers the action, side effects, usage context, parameter details, and return value. It also mentions which sibling tools will use the loaded spec, providing full context.
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?
The input schema has 0% description coverage for the single parameter 'path'. The description compensates fully by specifying that the path must be an absolute path to a .qa.xml file on the local machine, adding meaning beyond the schema's type and title.
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 loads a .qa.xml spec file at runtime, using a specific verb and resource. It distinguishes from sibling tools (which operate on an already-loaded spec) by emphasizing that this tool replaces any previously loaded spec and sets the file for subsequent spec operations.
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 provides explicit guidance on when to use this tool: when the spec path is only known at conversation time (e.g., a file on OneDrive) instead of pre-configuring PROSUITE_SPEC_PATH. It also explains that subsequent spec tools use the new file, implying when not to use (if the path is already configured).
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?
With no annotations, the description fully covers behavioral traits: it explains the output format including status, total_errors, and per-condition breakdown, error handling via 'status': 'error', and special behavior for output_dir (only defaults to local runs/ when PROSUITE_HOST is local). Also discloses the envelope spatial filter.
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 paragraphs and bullet points, using clear labels like 'Args:' and 'Returns:'. Every sentence provides necessary detail without redundancy. It is concise yet comprehensive for a complex tool.
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 (6 parameters, nested objects, output schema not shown), the description covers prerequisites, all parameters with special cases, return format, and error handling. It leaves no critical gaps for an AI agent to invoke the tool correctly.
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?
The description adds substantial meaning beyond the input schema, which has 0% coverage. It explains each parameter's purpose, format, and examples: model_catalog_path as server workspace path, datasets with optional filter_expression, conditions with method names and params, output_dir with server-side write access caveat, and envelope as spatial filter.
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 uses a specific verb 'Run' and resource 'ProSuite quality verification', clearly stating its purpose. It differentiates from siblings like list_conditions and preview_condition_run by focusing on executing an ad-hoc condition list against a workspace.
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 explains the prerequisite environment variables (PROSUITE_HOST/PROSUITE_PORT) and the service reachability requirement. It does not explicitly state when to avoid this tool or suggest alternatives, but the context of building an ad-hoc condition list vs. running pre-defined specs is implied.
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?
With no annotations, the description fully discloses key behaviors: case-insensitive literal matching, max_results cutoff, the meaning of allow_errors, the 'unsupported' flag and its implications for run_verification vs run_xml_verification, and the active spec resolution. This goes well beyond a simple summary.
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 organized into clear sections: purpose, matching behavior, result fields, unsupported note, and active spec context. Each sentence adds information without redundancy; it is appropriately sized for a tool with no output schema.
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?
The description covers output structure (result fields, status), edge cases (unsupported), and environmental dependence (active spec), which is sufficient for an agent to invoke correctly. There is no output schema, so this level of detail is necessary and complete.
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?
Although the schema only provides titles, the description explains query as a natural-language string matched against name, description, or category, and max_results as the cap on returned results. It also clarifies the language requirement, which is not evident from the schema.
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 'Search the loaded QA spec for conditions matching a natural-language query.' It specifies the resource (QA spec), the action (search), and the output type (conditions). The subsequent details about literal substring matching and language support further distinguish it from sibling tools like list_conditions.
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 explains the search semantics (literal substring, not semantic) and notes the active spec selection behavior, giving users context for when to invoke it. It does not explicitly name alternatives, but the behavior description implies it is for finding specific conditions, as opposed to listing or describing.
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:

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

Score Badge

Copy to your README.md:

[![prosuite-mcp MCP server](https://glama.ai/mcp/servers/ProSuite/prosuite-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ProSuite/prosuite-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/ProSuite/prosuite-mcp'

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