spx-mcp-server

Server Quality Checklist

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

Latest release: v1.2.0
Disambiguation5/5
Each tool has a clearly distinct purpose: profile_url initiates profiling, list_reports lists metadata, get_report_metadata retrieves specific metadata, analyze_report aggregates full data, get_hot_paths extracts hot paths, get_function_profile provides function-level analysis, and get_raw_events returns raw events. There is no ambiguity between them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in lowercase snake_case (e.g., profile_url, list_reports, get_hot_paths). The verbs are clear and the naming is predictable throughout.
Tool Count5/5
With 7 tools, the server is well-scoped for a profiling/analysis domain. Each tool covers a necessary operation without bloat, and the count is ideal for an agent to manage.
Completeness4/5
The tool set covers the core workflow: starting a profile, listing reports, retrieving metadata, performing full analysis, and extracting specific insights. Minor gaps exist (e.g., no explicit tool to stop a profile or delete reports), but these are likely outside the server's intended scope, and the remaining tools form a cohesive surface.
Average 2.8/5 across 7 of 7 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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?
No annotations exist, and the description fails to disclose any behavioral traits such as read-only nature, authentication requirements, rate limits, or what 'hottest' means. The agent receives no information about side effects, permissions, or operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (9 words) but underspecified rather than concise. Every sentence should earn its place; this single sentence omits critical information and does not justify its brevity.
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 7 parameters, no output schema, and no annotations, the description is completely inadequate. It does not explain what the tool returns, how to interpret the results, or how parameters interact. The tool's complexity demands far more detail.
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?
Schema description coverage is only 29% (2 of 7 parameters have descriptions). The one-sentence description adds no meaning to any parameter—it does not explain 'key', 'limit', 'metric', 'timeoutMs', or 'maxPathDepth'. The description fails to compensate for the low schema coverage.
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 'Return only the hottest call paths for one SPX report,' which indicates a specific verb, resource, and scope. However, 'hottest' is ambiguous and not defined, nor does it differentiate from sibling tools like analyze_report or get_function_profile. The purpose is somewhat clear but lacks precision.
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 mentions 'for one SPX report' implying a prerequisite, but provides no guidance on when to use this tool versus alternatives (e.g., get_raw_events, get_function_profile). No exclusions, prerequisites, or context for selection are given.
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?
The description mentions multi-step processing (download, decompress, parse, aggregate), hinting at resource usage and potential network activity. However, it provides no details about side effects, error cases, return format, or performance implications, and there are no annotations to compensate.
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 concise sentence with no wasted words. However, it lacks structure such as bullet points or sections, and could benefit from more detail without becoming overly verbose.
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 complexity (7 parameters, multi-step processing, no output schema), the description is severely incomplete. It does not explain what 'aggregate' means, what the return value is, how to configure the download/parsing, or any error scenarios. The agent would struggle to use this tool correctly.
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?
The description does not explain any of the seven parameters, even though schema description coverage is only 43%. Parameters like limit, metric, timeoutMs, and maxPathDepth have no explanations in either the description or the schema, leaving the agent unable to understand their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific actions (download, decompress, parse, aggregate) on 'one SPX full report', which clearly indicates the tool's purpose. However, it does not explicitly differentiate from siblings like get_hot_paths or get_function_profile, which could be used for more granular analysis.
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 on when to use this tool versus alternatives, prerequisites, or contexts where it would be inappropriate. The description only states what it does, not when to use it.
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 present, so the description carries full burden. It only states the action without disclosing behavioral traits: no mention of whether the operation is read-only, what happens on error (e.g., missing key), rate limits, or authentication requirements.
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, front-loaded with the verb and resource. It wastes no words. However, it might be slightly under-specified given the existence of four parameters; additional concise details could improve it without harming 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 no output schema, the description should hint at what the metadata JSON contains, or at least state the return type. It does not. Additionally, with four parameters (one required), the lack of any parameter explanation makes the tool description incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (two of four parameters have descriptions in the schema), but the tool description adds no parameter information. The key parameter is referenced implicitly ('one SPX report key') but not explained (e.g., format, where to obtain it). The description does not compensate for the missing schema descriptions for 'key' and 'timeoutMs'.
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 'Get' and the resource 'metadata JSON for one SPX report key', making the core function explicit. However, it does not distinguish itself from siblings like 'list_reports' or 'analyze_report', which might also return metadata.
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. The description lacks context about prerequisites (e.g., needing a valid report key), when to prefer it over 'list_reports' (which might list keys), or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool is 'for a function name substring' (implying partial matching) and returns multiple profile components, but does not state whether it is a read-only operation, whether data could be stale, what format the response takes, or any side effects. The lack of detail on invocation behavior (e.g., if it modifies state, requires authentication) is a significant gap.
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 concise sentence—front-loaded with the main purpose (Return aggregate, callers, callees, and hot paths) and ending with the search qualifier ('for a function name substring'). No wasted words, but slightly more detail on how the substring matching behaves could improve it without becoming verbose.
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 tool's moderate complexity (8 parameters, 2 required, no output schema, no annotations), the description is incomplete. It does not explain what 'key' or 'metric' are, how the substring search works (e.g., case sensitivity, wildcards), what the return format looks like, or any usage prerequisites. The description is too brief for the tool's richness and lacks critical context for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (25%), meaning the description must compensate for the 6 parameters without inline schema documentation. The description does not add meaning for any of the 8 parameters—it lists output components (aggregate, callers, callees, hot paths) but these are not parameters. The description adds no extra value over the schema for key, limit, metric, spxKey, baseUrl, timeoutMs, maxPathDepth, or functionQuery. Since coverage is low, a score of 3 is generous; the description fails to explain what key or metric mean or how functionQuery pattern matching works.
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 uses a specific verb phrase 'Return aggregate, callers, callees, and hot paths' and clearly identifies the resource as 'a function name substring'. It distinguishes the tool from siblings like get_hot_paths by mentioning multiple profile components (aggregate, callers, callees) rather than just hot paths.
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 such as get_hot_paths, profile_url, or analyze_report. There is no mention of prerequisites (e.g., an existing SPX profile), context for using the substring-based functionQuery, or when one might prefer a sibling tool.
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?
With no annotations provided, the description must disclose behavioral traits. It mentions sending SPX cookies and profiling a request, hinting at side effects (cookie injection). However, it does not clarify whether the request is actually executed, what happens on failure, or if the method affects behavior. The 'profile' verb is somewhat ambiguous—does it merely observe or also modify the request? 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?
The description is a single sentence with no wasted words. It is front-loaded with the main action. However, it could be slightly expanded to cover the 'how' without losing conciseness—currently it is lean but somewhat incomplete.
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 complexity (10 parameters, no output schema, no annotations, low schema coverage), the description is insufficient. It does not explain what a 'profile' is, what the output looks like, or how parameters like depth and metrics affect behavior. The agent needs more context to use this tool effectively, especially since there is no output schema to compensate.
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 low (30%), so the description should compensate. The description adds no parameter-specific details beyond what the schema provides. The schema itself has descriptions for only 3 of 10 parameters (spxKey, baseUrl, allowCrossOrigin). The description does not explain the meaning of depth, metrics, builtins, or samplingPeriod, leaving the agent with incomplete understanding. Baseline 3 for low coverage with no added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Profile one web request by sending SPX cookies to the target URL,' which clearly identifies the verb (profile), resource (web request), and mechanism (SPX cookies). It is distinct from sibling tools like list_reports or analyze_report, but could be more explicit about the output being a profile rather than a report.
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. It does not mention prerequisites (e.g., must have a valid SPX session) or when not to use it (e.g., for simple requests without profiling). The siblings are all report/analysis tools, so the core use case is implied but not explained.
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 must disclose behavioral traits. It only states the basic operation (listing metadata) but does not mention whether this is a read-only operation, if authentication via spxKey is required, what happens with missing keys, rate limits, pagination, or any side effects. The implied behavior is minimal.
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 11-word sentence that is front-loaded with the verb 'List' and the main resource. Every word is necessary and there is no redundancy or wasted text.
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?
The tool has 3 optional parameters and no output schema. The description fails to mention whether the list is paginated, filtered, or ordered; what the metadata structure looks like; or any prerequisites such as needing an active SPX key. Agents are left to guess the return format and behavior.
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 provides descriptions for spxKey and baseUrl (67% coverage). The description adds context that the endpoint is 'embedded web UI data', which helps clarify the purpose of baseUrl and spxKey. However, it does not elaborate on timeoutMs or provide parameter-specific guidance beyond what the schema already offers. Baseline 3 is appropriate given the 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 uses a specific verb 'List' and identifies the resource 'SPX report metadata' and the source 'embedded web UI data endpoint'. This clearly distinguishes it from siblings like 'get_report_metadata' (which implies retrieving a single report's metadata) and 'analyze_report' (which implies deeper analysis).
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 such as get_report_metadata for a single report or analyze_report for analysis. It does not state prerequisites, limitations, or scenarios where this tool is appropriate or inappropriate.
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?
With no annotations provided, the description carries the full burden of disclosing behavior. It mentions pagination and the non-full-report nature, which is useful, but it does not explicitly state whether this is a read-only operation, nor does it mention authentication needs, side effects, or error behavior. This leaves significant gaps.
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 long, front-loaded with the primary action, and contains zero wasted words. It efficiently conveys the tool's core function and a key limitation.
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 tool has 7 parameters, no output schema, and no annotations, the description is too thin. It does not explain what 'raw SPX events' are, what 'key' refers to, how pagination works in practice, or what the return format looks like. Sibling tools are not mentioned as alternatives, and there is no guidance on when this debug view is appropriate versus a full report. This is inadequate for the tool's complexity.
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 71% (5 of 7 parameters documented), so the baseline is 3. The description adds no parameter-specific details; it only hints at pagination via the word 'paginated'. It does not compensate for undocumented 'key' and 'timeoutMs' parameters, but the existing schema descriptions handle most of the burden.
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 'Return a paginated debug slice of raw SPX events' uses a specific verb and resource, clearly distinguishing this tool from siblings that deal with reports, profiles, and hot paths. The added caveat 'This never returns the full report' further clarifies its scope and purpose.
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 that this is a debug-oriented tool returning partial raw events, and explicitly notes it never returns the full report. However, it does not name alternatives or state when-not-to-use this tool, so it stops short of being fully explicit.
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:

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

Score Badge

Copy to your README.md:

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

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/szepeviktor/spx-mcp-server'

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