Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PeakInfer MCP Server detect drift between my code and runtime behavior"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Achieve peak inference performance in Claude Desktop and Claude Code.
PeakInfer helps you run AI inference at peak performance by correlating what no one else sees together: your code, runtime behavior, benchmarks, and evals.
Your code says streaming: true. Runtime shows 0% actual streams. That's drift—and it's killing your latency.
Peak Inference Performance means: Improving latency, throughput, reliability, and cost without changing evaluated behavior.
Related MCP server: LUMINO MCP Server
Drift Detection: Find mismatches between code declarations and runtime behavior
Runtime Connectors: Fetch events from Helicone and LangSmith
Benchmark Comparison: Compare your metrics to InferenceMAX benchmarks (15+ models)
Template Library: Access 43 optimization templates
Analysis History: Track and compare performance over time
npx @kalmantic/peakinfer-mcpnpm install -g @kalmantic/peakinfer-mcp
peakinfer-mcpAdd to ~/.config/claude/claude_desktop_config.json (macOS) or %APPDATA%\claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"peakinfer": {
"command": "npx",
"args": ["@kalmantic/peakinfer-mcp"],
"env": {
"HELICONE_API_KEY": "your-key-here",
"LANGSMITH_API_KEY": "your-key-here"
}
}
}
}git clone https://github.com/Kalmantic/peakinfer-mcp.git
cd peakinfer-mcp
npm install
npm run buildTool | Description |
| Fetch LLM events from Helicone |
| Fetch traces from LangSmith |
Tool | Description |
| Get benchmark data for a model |
| Compare current analysis to historical baseline |
Tool | Description |
| List available optimization templates |
| Get details of a specific template |
Tool | Description |
| Save analysis results to history |
Variable | Description |
| API key for Helicone integration |
| API key for LangSmith integration |
In Claude Desktop or Claude Code:
Fetch the last 7 days of events from Helicone and identify any drift between my code and runtime behavior.Compare my current p95 latency to InferenceMAX benchmarks for gpt-4o.Show me optimization templates for improving throughput without changing model behavior.The server also exposes MCP resources:
peakinfer://templates - Optimization templates (43 total)
peakinfer://benchmarks - InferenceMAX benchmark data (15+ models)
peakinfer://history - Analysis run history
Available prompt templates:
analyze-file - Analyze a file for LLM inference points
compare-benchmarks - Compare your metrics to peak benchmarks
suggest-optimizations - Get optimization recommendations that preserve behavior
PeakInfer analyzes every inference point across 4 dimensions:
Dimension | What We Find |
Latency | Missing streaming, blocking calls, p95 vs benchmark gaps |
Throughput | Sequential bottlenecks, batch opportunities |
Reliability | Missing retries, timeouts, fallbacks |
Cost | Right-sized model selection, token optimization |
Check the path to dist/index.js is absolute
Verify npm run build completed successfully
Restart Claude Desktop after config changes
Verify API keys are set in config env section
Check keys are valid at provider's dashboard
Ensure no trailing whitespace in key values
Apache-2.0
Analyze code for LLM inference issues using PeakInfer engine. Returns detailed report on latency, cost, throughput, and reliability with actionable fixes.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to the code directory or file to analyze | |
| files | No | Pre-read files array [{path, content}]. If provided, skips reading from disk. | |
| fixes | No | Include code fix suggestions (default: true) | |
| benchmark | No | Include benchmark comparisons (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the output (detailed report on latency, cost, throughput, reliability, and fixes), but does not clarify whether the tool has side effects, requires specific permissions, or is strictly read-only. The mention of 'actionable fixes' could imply code modification, but it remains ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and output. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description provides a high-level return summary but lacks detail on report shape, whether files are modified, or how results are structured. Given its complexity (4 params) and zero output schema, it is complete enough for tool selection but leaves gaps for invocation expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage), so baseline is 3. The description adds extra semantic value by framing the output dimensions (latency, cost, etc.) and the engine, which enriches understanding of the 'fixes' and 'benchmark' parameters, pushing it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Analyze') and resource ('code for LLM inference issues using PeakInfer engine'), and distinguishes itself from sibling tools like get_helicone_events or get_inferencemax_benchmark by focusing on code analysis rather than trace retrieval or benchmark comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for code-level inference analysis, but provides no explicit guidance on when to choose this tool over siblings or when not to use it. It lacks exclusions or alternative mentions, so the context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare current analysis results to a historical baseline
| Name | Required | Description | Default |
|---|---|---|---|
| baseline_path | No | Path to baseline JSON file | |
| current_analysis | Yes | Current analysis results (InferenceMap format) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the high-level action. It does not disclose whether the tool is read-only, how it handles a missing baseline_path, or what the comparison result looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise but could arguably benefit from a second sentence to clarify the return value, yet it remains appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too sparse to understand the tool's behavior fully. It does not explain the return format, failure modes, or how the comparison is performed, making it incomplete for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with descriptions (100% coverage). The description in the tool does not add extra syntax or format details, but it does align the two parameters with the concepts of 'current analysis' and 'baseline', so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Compare') with two resources: current analysis results and a historical baseline. This distinguishes it from sibling tools like analyze or save_analysis, though it lacks detail on the comparison output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool vs. alternatives. It does not specify prerequisites (e.g., baseline must exist) or when to prefer it over analyze/save_analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch LLM runtime events from Helicone for drift detection analysis
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days of data to fetch (default: 7) | |
| limit | No | Maximum number of events to fetch (default: 1000) | |
| api_key | No | Helicone API key (or set HELICONE_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. It states 'Fetch,' which implies a read operation, but fails to disclose authentication requirements (though the api_key parameter hints at this), pagination behavior (limit parameter implies batching but not explained), return format, or error handling. The description is too sparse to fully inform the agent about the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource, and it wastes no words. It precisely conveys the core functionality and context in an efficient manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately states what the tool does and why, but given the absence of an output schema and annotations, it should describe the return format or any notable behaviors. It doesn't mention what the events look like, whether they are returned as a list, or how drift detection uses them. With 3 parameters and no output schema, the description is minimally complete but lacks return-value context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of parameters, including defaults and explanations, so the baseline is 3. The description adds no additional semantic meaning to the parameters beyond noting the purpose of the fetch—it doesn't enrich the understanding of 'days' or 'limit' beyond what's already in the schema. Thus, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action ('Fetch'), the resource ('LLM runtime events from Helicone'), and its intended use ('for drift detection analysis'). This distinguishes it from sibling tools like get_langsmith_traces, which operate on different data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need Helicone events for drift detection analysis. However, it does not explicitly exclude alternatives like get_langsmith_traces or compare_to_baseline, nor does it mention when not to use this tool. The 'for drift detection analysis' clause implies the usage domain, but no explicit alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get InferenceMAX benchmark data for a specific model to compare performance
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name (e.g., gpt-4o, claude-3-5-sonnet, llama-3.1-70b) | |
| hardware | No | Hardware: api, h100, a100 (default: api) | api |
| framework | No | Framework: api, vllm, tgi, sglang (default: api) | api |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It indicates a read-only retrieval action via 'Get' and describes the data as 'benchmark data', but it does not disclose potential side effects, response format, error behavior, or any constraints. For a simple read tool, this is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the tool's purpose. It contains no redundant details or filler, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, three well-documented parameters, and no output schema, the description sufficiently conveys the tool's core function. However, it could be more complete by explicitly mentioning the optional hardware/framework filtering or the nature of the returned benchmark data, but the schema covers those details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of parameter meanings, including examples and defaults. The description adds no additional parameter-level semantics beyond reiterating 'specific model', which is already in the schema. The baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves InferenceMAX benchmark data for a specific model, using a specific verb ('Get') and resource ('InferenceMAX benchmark data'). It distinguishes from sibling tools like get_helicone_events and get_langsmith_traces by naming a distinct data source and adding the purpose of performance comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing benchmark data for a specific model, but it does not explicitly state when to use this tool over alternatives like compare_to_baseline. There is no mention of exclusions or alternative tools, so guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch LLM traces from LangSmith for runtime analysis
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days of data to fetch (default: 7) | |
| limit | No | Maximum number of traces to fetch (default: 1000) | |
| api_key | No | LangSmith API key (or set LANGSMITH_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not specify whether the operation is read-only, whether it has side effects, rate limits, or performance implications. The description mentions 'fetch' but omits details about output structure or authentication requirements beyond what is in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the verb and resource. It contains no redundant information and is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what the returned traces look like or how they are structured. It does not. Additionally, it lacks context on the optional parameters' practical effects or when to customize defaults, making it insufficient for a tool with 3 optional parameters and no required ones.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all three parameters (days, limit, api_key), covering 100% of the parameter semantics. The tool description adds no further meaning or context about these parameters, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Fetch) and the resource (LLM traces from LangSmith), along with the purpose (runtime analysis). It distinguishes itself from sibling tools like get_helicone_events and get_inferencemax_benchmark by specifying the exact data source and type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, or any exclusions or prerequisites. The description only states what the tool does, leaving the agent to infer usage from the sibling list and tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific optimization template
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Template name (e.g., overpowered-model, streaming-drift) |
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 only says 'Get details' and doesn't state whether the operation is read-only, how missing templates are handled, or what the response structure is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, this is minimally viable. However, no output schema exists and the description doesn't specify return details or error behavior, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single 'name' parameter with a clear description and examples. The tool description adds no additional parameter semantics, but with 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('details of a specific optimization template'). It distinguishes from list_templates by implying a single named template, but doesn't explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It doesn't mention that list_templates should be used to discover template names, nor any preconditions or edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available PeakInfer optimization templates
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category: insights, optimizations, all (default: all) | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the tool's function without adding details such as read-only nature, return format, pagination, or any limitations beyond the category filter in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It is front-loaded and easily parsable, though it lacks additional context that could be included without harming brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain what the returned data looks like and how to use it alongside sibling tools like get_template. It does neither, leaving the agent without enough context for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter documentation with a clear description of category. The description adds no additional meaning to the parameter beyond what the schema already provides, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'available PeakInfer optimization templates', which distinguishes this collection-browsing tool from the sibling get_template tool that retrieves a single template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_template, analyze, or compare_to_baseline. It simply states what it does without specifying discovery workflows or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save analysis results to PeakInfer history
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to save results (default: .peakinfer/runs/) | |
| analysis | Yes | Analysis results to save (InferenceMap format) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it saves results, but does not disclose side effects such as overwriting existing files, whether a run is created if none exists, permissions required, or error behavior. For a mutation tool, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the tool's function without any filler. It is appropriately sized and front-loaded, satisfying the conciseness criterion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has a nested object parameter, no output schema, and no annotations, the description is too sparse. It does not explain what 'PeakInfer history' is, how the path is used, what happens on success, or how this integrates with sibling tools like analyze. The contextual information is insufficient for reliable tool selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters (path default, analysis format), so schema coverage is 100%, reaching the baseline of 3. The tool description adds no additional meaning beyond 'save analysis results,' which does not clarify the InferenceMap format or the path resolution behavior beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Save') and its resource ('analysis results') with a destination ('PeakInfer history'). It distinguishes itself from sibling tools like analyze, which likely runs analyses, and the get_* tools, which retrieve external data. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives or prerequisites. It does not mention that it should be used after an analysis is performed, nor does it explain when to prefer saving over other actions. The sibling context implies a workflow but the description itself offers no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.1analyzecompare_to_baselineget_helicone_eventsget_inferencemax_benchmarkget_langsmith_tracesget_templatelist_templatessave_analysisScored across 8 tools
Most tools target distinct actions and resources. The only potential confusion is between get_helicone_events and get_langsmith_traces, but their descriptions clearly indicate different source platforms, making them distinguishable.
Tool names follow a consistent verb_noun snake_case pattern with get_*, list_*, save_*, and compare_to_*. The exception is 'analyze' which lacks an explicit object, but its purpose is still clear from the description.
Eight tools is a well-scoped set that covers code analysis, external data retrieval, benchmarking, template management, and persistence without unnecessary bloat. It fits the 3-15 tool range comfortably.
The set covers analysis, saving, comparison, and template browsing, but lacks any way to retrieve or list previously saved analyses. This creates a dead end after saving, as agents cannot access historical results directly.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Conformance checker for MCP servers. Free, no key, verdicts recomputable and re-measured daily.
