list_shared_reportsList the share links that exist for a test run, with their access level and expiry. Requires project context.
| Name | Required | Description | Default |
|---|---|---|---|
| testRunId | Yes | Public Id (Guid) of the test run |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation is true, and the verb 'list' is inherently read-only, with no contradiction. The description adds no side-effect expectations, which is appropriate for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and directly to the point. It includes all necessary details without any redundant phrasing or fluff.
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 there is no output schema, mentioning that the result includes access level and expiry provides a partial output preview. The note about requiring project context is a practical prerequisite, making the description sufficiently complete for an agent to use the tool 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 describes the testRunId parameter as 'Public Id (Guid) of the test run', and the tool description references it contextually with 'for a test run'. This reinforces the parameter's meaning without adding new information, but the alignment is clear.
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 (list), the resource (share links), and the scope (for a test run). It also specifies the output fields (access level and expiry), leaving no ambiguity about the tool's purpose.
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 explicitly notes that project context is required, which is a useful prerequisite. It does not name alternatives, but the sibling list of many list_* tools makes the differentiation clear based on the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The tools are mostly distinct with clear descriptions. Some pairs like get_header_policies vs get_resolved_headers or get_environment_verification vs get_monitoring_sync_status could be slightly confusing, but the descriptions clarify scope and purpose.
All tools follow a consistent snake_case verb_noun pattern (get_, list_, create_, update_, manage_, etc.). Even the few bare verbs like 'search' and 'set_context' are consistent with the naming scheme.
With 165 tools, the server is extremely heavy. This far exceeds the 'too many' threshold of 25+, making it difficult for an agent to navigate and select the right tool efficiently.
The tool surface covers a very broad API lifecycle domain: specs, environments, test cases, monitors, mock servers, security, governance, documentation, and team management. Read and write operations are present across most areas, with no obvious missing core functionality.