Click on "Install 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., "@perfsonar-mcp Check the packet loss between host-a and host-b over the last 24 hours"
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.
MCP (Model Context Protocol) server for perfSONAR - Query measurements, discover testpoints, and schedule network tests.
Query historical measurements with filters
Get throughput, latency, and packet loss data
Access raw time-series data with summaries
Discover available measurement types
Find perfSONAR testpoints globally
Search by location (city, country)
Locate pScheduler services for testing
Schedule throughput tests (iperf3)
Schedule latency tests (owping)
Schedule RTT tests (ping)
Monitor test status and retrieve results
Related MCP server: PacketMaster
pip install -e .For development with additional tools:
pip install -e '.[dev]'Required environment variable:
export PERFSONAR_HOST=perfsonar.example.comOptional:
export LOOKUP_SERVICE_URL=https://lookup.perfsonar.net/lookup
export PSCHEDULER_URL=https://perfsonar.example.com/pschedulerStandard MCP stdio transport for local AI clients:
python -m perfsonar_mcp
# or
perfsonar-mcpFastMCP enables web-accessible MCP server via SSE (Server-Sent Events) or HTTP:
# SSE transport (recommended for web)
export PERFSONAR_HOST=perfsonar.example.com
fastmcp run src/perfsonar_mcp/fastmcp_server.py --transport sse --host 0.0.0.0 --port 8000
# HTTP transport (alternative)
fastmcp run src/perfsonar_mcp/fastmcp_server.py --transport http --host 0.0.0.0 --port 8000
# Or use the convenience command
perfsonar-mcp-webThe server will be accessible at:
SSE: http://your-host:8000/sse
HTTP: http://your-host:8000/mcp/
docker-compose up -dhelm install perfsonar-mcp ./helm/perfsonar-mcp \
--set config.perfsonarHost=perfsonar.example.comAdd to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"perfsonar": {
"command": "python",
"args": ["-m", "perfsonar_mcp"],
"env": {
"PERFSONAR_HOST": "your-perfsonar-host.example.com"
}
}
}
}For web-based access, use the SSE endpoint:
{
"mcpServers": {
"perfsonar-web": {
"url": "http://your-server:8000/sse",
"transport": "sse"
}
}
}query_measurements - Search measurements
get_throughput - Throughput data
get_latency - Latency data
get_packet_loss - Packet loss data
get_measurement_data - Raw time-series
get_available_event_types - List types
lookup_testpoints - Find testpoints
find_pscheduler_services - Find pScheduler
schedule_throughput_test - Run throughput test
schedule_latency_test - Run latency test
schedule_rtt_test - Run RTT test
get_test_status - Check status
get_test_result - Get results
Ask Claude:
"Find perfSONAR testpoints in Europe"
"Schedule a 30-second throughput test to host.example.com"
"Get hourly throughput averages between host1 and host2 for the last week"
AI Agent (Claude)
↓ MCP Protocol (stdio)
perfSONAR MCP Server (Python)
├── Measurement Archive Client
├── Lookup Service Client
└── pScheduler Client
↓
perfSONAR ServicesWeb Clients / AI Agents
↓ HTTP/SSE
FastMCP Web Server (uvicorn)
↓ MCP Protocol
perfSONAR MCP Server (Python)
├── Measurement Archive Client
├── Lookup Service Client
└── pScheduler Client
↓
perfSONAR ServicesBoth transports expose the same tools and capabilities. The web transport enables:
Remote access from any HTTP client
Multiple concurrent connections
Integration with web-based AI applications
RESTful API-like access patterns
The server includes comprehensive logging for development and debugging. By default, logs are written to stderr at INFO level.
To enable DEBUG logging for more detailed output:
import logging
logging.basicConfig(level=logging.DEBUG)Or set the log level via environment variable:
export PYTHONLOGLEVEL=DEBUG
python -m perfsonar_mcpLog output includes:
Server initialization and configuration
API requests and responses
Tool invocations with arguments
Error details with stack traces
Open in VS Code → Reopen in Container
# Install with dev dependencies
pip install -e '.[dev]'
# Format code
black src/perfsonar_mcp/
# Lint code
ruff check src/perfsonar_mcp/
# Type check
mypy src/perfsonar_mcp/
# Run tests
pytest tests/MIT
Find pScheduler services for running tests.
| Name | Required | Description | Default |
|---|---|---|---|
| locationCity | No | City filter | |
| locationCountry | No | Country filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool finds services for running tests but doesn't disclose key traits like whether it's read-only or mutative, authentication needs, rate limits, or what the output format looks like. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for the tool's complexity.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'pScheduler services' are, what 'running tests' entails, or what the return values look like (e.g., a list of services, their statuses). For a tool with no structured behavioral data, more context is needed to guide the agent effectively.
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 description coverage is 100%, so the input schema already documents both parameters ('locationCity' and 'locationCountry') as filters. The description implies filtering by location but doesn't add meaning beyond what the schema provides, such as how filters combine or examples of usage. Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose with a specific verb ('Find') and resource ('pScheduler services'), making it understandable. However, it doesn't distinguish this tool from sibling tools like 'lookup_testpoints' or 'query_measurements', which might also involve finding or querying network-related data, so it lacks explicit differentiation.
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. It doesn't mention any prerequisites, context for use, or exclusions, leaving the agent to infer usage based on the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all available event types in the archive.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Source filter | |
| destination | No | Destination filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does ('Get all available event types') without mentioning any behavioral traits like whether it's read-only, has rate limits, requires authentication, returns paginated results, or what format the output takes. This leaves significant gaps for a tool with no structured safety hints.
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, efficient sentence that directly states the tool's purpose without any unnecessary words or fluff. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It fails to address key contextual aspects such as the behavior of the tool (e.g., read/write nature, error handling), output format, or how it relates to sibling tools. For a tool with no structured safety or output information, the description should provide more guidance to be fully helpful.
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 description coverage is 100%, with both parameters (source and destination) documented in the schema as filters. The description does not add any meaning beyond this, such as explaining how these filters work or providing examples. Since the schema handles the parameter documentation adequately, the baseline 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 states the verb ('Get') and resource ('all available event types in the archive'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this tool from its siblings (e.g., other 'get_' tools like get_latency or get_throughput), which would require a 5.
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 other sibling tools like query_measurements or get_measurement_data. It lacks any context about prerequisites, exclusions, or typical use cases, leaving the agent with minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get latency/delay measurements between source and destination.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source host/IP address | |
| destination | Yes | Destination host/IP address | |
| timeRange | No | Time range in seconds | |
| summaryWindow | No | Summary window in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s]' measurements, implying a read operation, but lacks details on permissions, rate limits, whether it returns real-time or historical data, or any side effects. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core purpose, making it easy to understand quickly. Every part of the sentence contributes directly to explaining the tool's function.
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 complexity of latency measurement tools and the lack of annotations and output schema, the description is incomplete. It does not cover behavioral aspects like data freshness, error handling, or return format, leaving gaps that could hinder an AI agent's ability to use the tool effectively in context with siblings.
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 description coverage is 100%, so the schema already documents all parameters. The description adds minimal value beyond the schema by implying the parameters relate to source and destination for measurements, but does not provide additional context like format examples or usage tips. Baseline 3 is appropriate when the schema handles most documentation.
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's purpose with a specific verb ('Get') and resource ('latency/delay measurements'), specifying what is being measured ('between source and destination'). It distinguishes from some siblings like 'get_packet_loss' or 'get_throughput' by focusing on latency, but could be more explicit about differentiation from 'schedule_latency_test'.
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. It does not mention prerequisites, context, or exclusions, such as how it differs from 'schedule_latency_test' (which might schedule a test rather than retrieve measurements) or 'get_measurement_data' (which could be more general).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get raw time-series data for a specific measurement.
| Name | Required | Description | Default |
|---|---|---|---|
| metadataKey | Yes | Metadata key from query | |
| eventType | Yes | Event type | |
| summaryType | No | Summary type | |
| summaryWindow | No | Summary window in seconds | |
| timeRange | No | Time range in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'gets' data, implying a read-only operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, data format, or potential side effects. This is inadequate for a tool with 5 parameters and no output 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, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly.
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 complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'raw time-series data' entails, how parameters interact, or what the return values are, leaving significant gaps for an AI agent to understand the tool's behavior.
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 description coverage is 100%, so the schema already documents all 5 parameters. The description adds no additional meaning beyond implying time-series data retrieval, which aligns with parameters like 'timeRange' and 'summaryWindow'. Baseline 3 is appropriate as the schema handles parameter documentation.
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 ('raw time-series data for a specific measurement'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'get_latency', 'get_packet_loss', or 'get_throughput', which also retrieve measurement-related data, so it lacks sibling differentiation.
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. It doesn't mention prerequisites, context (e.g., after querying measurements), or comparisons to siblings like 'query_measurements' or other 'get_' tools, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get packet loss measurements between source and destination.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source host/IP address | |
| destination | Yes | Destination host/IP address | |
| timeRange | No | Time range in seconds | |
| summaryWindow | No | Summary window in seconds |
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 states what the tool does but fails to describe how it behaves—e.g., whether it's a read-only operation, if it requires authentication, what the output format looks like, or any rate limits. This leaves significant gaps for an agent to understand the tool's operational traits.
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, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 complexity (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns, how measurements are calculated, or any behavioral nuances. For a tool that likely involves network diagnostics, more context is needed to guide effective usage.
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 has 100% description coverage, so all parameters are documented in the schema itself. The description adds no additional meaning beyond what's in the schema, such as explaining how 'timeRange' and 'summaryWindow' interact or providing examples. This meets the baseline score of 3, as the schema handles the heavy lifting.
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's purpose as 'Get packet loss measurements between source and destination,' which is a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'get_latency' or 'get_throughput' that also retrieve network measurements, leaving room for confusion about when to use each.
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 like 'get_latency' or 'get_throughput' from the sibling list. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based solely on the tool name and basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get result of a completed pScheduler test.
| Name | Required | Description | Default |
|---|---|---|---|
| runUrl | Yes | Run URL from test scheduling |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what format the result returns (e.g., JSON, raw data). This leaves significant gaps for an agent to use it correctly.
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, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary details.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what the result looks like (e.g., data format, structure), error cases, or dependencies on other tools like scheduling tests. For a tool with one parameter but critical behavioral unknowns, this is inadequate.
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 description coverage is 100%, so the schema already documents the 'runUrl' parameter fully. The description doesn't add any meaning beyond what the schema provides, such as examples or context for the run URL. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get result') and resource ('completed pScheduler test'), making the purpose understandable. It distinguishes from siblings like 'get_test_status' by focusing on results rather than status, though it doesn't explicitly mention this distinction.
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 on when to use this tool versus alternatives like 'get_test_status' or other measurement tools. The description implies usage for completed tests but doesn't specify prerequisites, error conditions, 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.
Get status of a pScheduler test run.
| Name | Required | Description | Default |
|---|---|---|---|
| runUrl | Yes | Run URL from test scheduling |
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 states the tool retrieves status but doesn't explain what 'status' entails (e.g., running, completed, failed), whether it's read-only or has side effects, or any constraints like rate limits or authentication needs, leaving key behavioral traits unspecified.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete for a tool that likely returns status details. It doesn't explain what information the status includes (e.g., progress, errors) or how to interpret results, leaving gaps in understanding the tool's full context and output.
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 has 100% description coverage, with 'runUrl' documented as 'Run URL from test scheduling'. The description adds no additional meaning beyond this, such as format examples or context about where to obtain the URL, so it meets the baseline for high schema coverage without enhancing parameter understanding.
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 status') and resource ('pScheduler test run'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_test_result' or 'get_measurement_data', which might provide related information about test outcomes or data.
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. It doesn't mention prerequisites, such as needing a scheduled test run, or clarify its role compared to siblings like 'get_test_result' or 'get_measurement_data', leaving usage context ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get throughput measurements between source and destination.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source host/IP address | |
| destination | Yes | Destination host/IP address | |
| timeRange | No | Time range in seconds | |
| summaryWindow | No | Summary window in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic function. It doesn't cover critical aspects like whether this is a read-only operation, if it requires authentication, rate limits, error handling, or what the output format might be, leaving 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the core purpose. It's appropriately sized for the tool's complexity, making it easy to parse quickly.
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 no annotations and no output schema, the description is incomplete for a tool with 4 parameters and network measurement complexity. It fails to explain behavioral traits, return values, or usage context, leaving the agent under-informed despite the clear schema.
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 description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying that parameters define the measurement context, which aligns with the schema but doesn't enhance it, meeting the baseline for high coverage.
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 ('throughput measurements') with scope ('between source and destination'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_latency' or 'get_packet_loss' that also retrieve network metrics, missing full sibling distinction.
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 on when to use this tool versus alternatives. The description lacks context about prerequisites, timing, or comparisons to siblings like 'get_latency' or 'schedule_throughput_test', leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find perfSONAR testpoints using the lookup service.
| Name | Required | Description | Default |
|---|---|---|---|
| serviceType | No | Service type filter | |
| locationCity | No | City filter | |
| locationCountry | No | Country filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'finds' testpoints, implying a read-only query, but doesn't cover aspects like rate limits, authentication needs, error handling, or what the output looks like (e.g., list format, pagination). This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity (a query tool with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return values, error cases, or behavioral traits, leaving the agent with insufficient context to use the tool effectively beyond basic parameter passing.
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 description coverage is 100%, so the input schema already documents all three parameters (serviceType, locationCity, locationCountry) with basic descriptions. The description adds no additional meaning or examples beyond this, such as explaining what 'serviceType' might include or how filters combine. Baseline 3 is appropriate when the schema does the heavy lifting.
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 states the action ('Find') and resource ('perfSONAR testpoints') with the method ('using the lookup service'), providing a basic purpose. However, it doesn't differentiate from sibling tools like 'find_pscheduler_services' or 'query_measurements', which might involve similar search/find operations, leaving the scope vague.
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 on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., for network performance testing), or exclusions, leaving the agent to infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query perfSONAR measurements with optional filters. Returns metadata about available measurements.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Source host/IP address | |
| destination | No | Destination host/IP address | |
| eventType | No | Event type to filter | |
| toolName | No | Tool name to filter | |
| timeRange | No | Time range in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'returns metadata about available measurements.' It doesn't disclose whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior, error conditions, or what format the metadata takes. The description is minimal and lacks essential behavioral context.
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, efficient sentence that states the core purpose. It's appropriately sized for a query tool, though it could be slightly more informative without losing conciseness. No wasted words or redundant information.
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 query tool with 5 parameters and no output schema or annotations, the description is insufficient. It doesn't explain what 'metadata' includes, how results are structured, whether filtering is AND/OR logic, or any performance characteristics. Given the complexity implied by multiple filter parameters and sibling tools, more context is needed for effective 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?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds marginal value by mentioning 'optional filters' which aligns with the schema's optional parameters, but doesn't provide additional context about parameter relationships, typical values, or filtering logic beyond what's in the schema.
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 ('query') and resource ('perfSONAR measurements') with the purpose of returning metadata about available measurements. It distinguishes itself from siblings like get_measurement_data (which likely returns actual data) by focusing on metadata, but doesn't explicitly contrast with all measurement-related tools.
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 mentions 'optional filters' but provides no guidance on when to use this tool versus alternatives like get_latency, get_throughput, or get_measurement_data. There's no indication of prerequisites, typical use cases, or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a latency test using pScheduler.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Source host (optional) | |
| dest | Yes | Destination host | |
| packetCount | No | Number of packets | |
| packetInterval | No | Interval between packets |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool schedules a test but doesn't explain what happens after scheduling (e.g., whether it returns a test ID, triggers immediate execution, or requires follow-up with 'get_test_status'). It also omits details like authentication needs, rate limits, or potential side effects, which are critical for a scheduling operation.
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, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 complexity of scheduling a network test (which likely involves asynchronous operations and follow-up tools), the description is incomplete. No annotations exist to clarify behavior, and there's no output schema to explain return values. The description fails to address key aspects like what the tool returns (e.g., a test ID), how to monitor test progress, or dependencies on other tools in the sibling list.
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 description coverage is 100%, meaning all parameters are documented in the input schema. The description adds no additional parameter information beyond what's in the schema (e.g., units for 'packetInterval', format for 'source'/'dest', or typical values). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 ('Schedule a latency test') and the system used ('using pScheduler'), which is a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'schedule_rtt_test' or 'schedule_throughput_test', which likely have similar scheduling functions but for different test types.
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 like 'schedule_rtt_test' or 'schedule_throughput_test'. It also doesn't mention prerequisites, context, or exclusions for scheduling latency tests, leaving the agent with no usage direction beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule an RTT (ping) test using pScheduler.
| Name | Required | Description | Default |
|---|---|---|---|
| dest | Yes | Destination host | |
| count | No | Number of pings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Schedule an RTT (ping) test', implying a write/mutation operation that initiates something, but doesn't cover permissions, side effects, response format, or any operational details like rate limits or idempotency, which are critical for a scheduling tool.
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, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words or repetition, making it highly 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 complexity of a scheduling tool with no annotations and no output schema, the description is incomplete. It lacks information on what happens after scheduling (e.g., returns a test ID, status), error handling, or dependencies, leaving significant gaps for the agent to understand the tool's full 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?
Schema description coverage is 100%, so the schema fully documents the two parameters ('dest' and 'count'). The description adds no additional meaning beyond what's in the schema, such as examples or constraints, but since the schema is complete, this meets the baseline for adequate parameter semantics.
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 ('Schedule') and resource ('RTT (ping) test using pScheduler'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'schedule_latency_test' or 'schedule_throughput_test', which would require mentioning what makes RTT/ping distinct from those other scheduling operations.
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. With siblings like 'schedule_latency_test' and 'schedule_throughput_test', there's no indication of whether RTT is a subset, complementary, or different type of test, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a throughput test using pScheduler.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Source host (optional) | |
| dest | Yes | Destination host | |
| duration | No | Test duration (e.g., PT30S) |
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 states the tool schedules a test, implying it's a write/mutation operation, but doesn't cover permissions, side effects, rate limits, or what happens after scheduling (e.g., how results are accessed). This is inadequate for a tool that likely initiates network tests.
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, efficient sentence with no wasted words. It front-loads the key action and tool context, making it easy to parse quickly.
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 complexity of scheduling network tests, lack of annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., a test ID), how to check status/results, or error handling. For a mutation tool with siblings, more context is needed.
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 description coverage is 100%, so the schema fully documents parameters. The description adds no additional meaning beyond what's in the schema (e.g., no examples of typical values or constraints). Baseline 3 is appropriate since the schema handles parameter documentation.
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 ('Schedule a throughput test') and specifies the tool used ('using pScheduler'), which distinguishes it from general scheduling tools. However, it doesn't explicitly differentiate from sibling tools like 'schedule_latency_test' or 'schedule_rtt_test' beyond the 'throughput' keyword in the name.
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 on when to use this tool versus alternatives like 'get_throughput' (which likely retrieves results) or other scheduling siblings. The description lacks context about prerequisites, timing, or when this tool is appropriate compared to direct measurement tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but there is some potential confusion between get_latency/get_packet_loss/get_throughput (all measurement retrievals) and schedule_latency_test/schedule_throughput_test (test scheduling). The descriptions clarify the action vs. scheduling distinction, but the similar naming could cause misselection.
All tools follow a consistent verb_noun pattern with snake_case throughout. The naming is highly predictable, using verbs like get, find, query, schedule, and lookup consistently across the toolset.
With 13 tools, this is well-scoped for a perfSONAR monitoring and testing server. The count is appropriate, covering service discovery, test scheduling, measurement retrieval, and data querying without being overwhelming.
The toolset provides strong coverage for the perfSONAR domain, including test scheduling, status/result retrieval, and measurement queries. A minor gap is the lack of tools for managing or canceling scheduled tests, which could limit workflow completeness.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
ThousandEyes MCP Server for network intelligence: outages, anomalies, alerts, events, and tests.
An MCP server giving access to Grafana dashboards, data and more.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
Public MCP server for summaries, DNS lookup, catalog, replies, and JSON checks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ajragusa/perfsonar-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
