Get aggregated quality scores for a service based on all past verifications. Returns average completeness, accuracy, pass rate, format compliance rate, SLA compliance rate, and quality trend.
| Name | Required | Description | Default |
|---|---|---|---|
| service_id | Yes | Service identifier to query (e.g. 'harvey-tools/scrape_url') |
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?
With no annotations provided, the description carries the full burden of disclosing behavior. It reveals that the tool returns specific aggregated metrics and that these are based on all past verifications, giving insight into its computational basis. However, it does not mention side effects, permissions, or potential limitations (e.g., whether it is read-only, latency, or behavior with no verifications).
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 long, front-loaded with the primary purpose, and lists the return metrics efficiently. Every sentence adds value, and there is no redundant or filler content.
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 (one parameter, no output schema), the description provides sufficient context by defining the input service_id, the aggregation basis (past verifications), and the returned metrics. It lacks details about response format (e.g., are rates decimals or percentages?) and edge cases, but these are not critical for basic 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 already provides full coverage for service_id, including a description and example. The tool description does not add additional meaning about the parameter beyond restating that it queries a service. Since schema coverage is 100%, the baseline of 3 is appropriate; the description adds no extra semantic value.
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 function: 'Get aggregated quality scores for a service based on all past verifications.' It uses a specific verb (Get) and resource (quality scores for a service), and it enumerates the outputs (completeness, accuracy, pass rate, etc.), which distinguishes it from sibling tools like verify_outcome or report_outcome that deal with individual verifications.
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 context: it aggregates past verifications, suggesting it is for reviewing overall service quality rather than individual outcomes. However, it does not explicitly state when to use this tool versus alternatives or mention any exclusions, such as 'use verify_outcome for individual checks'.
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.
Each tool performs a distinct function: health checks server status, list_tools discovers other tools, get_service_quality retrieves aggregated metrics, and report_outcome/verify_outcome record results at different granularities. Descriptions clearly differentiate between simple and detailed outcome reporting.
Four tools follow a consistent verb_noun pattern (get_service_quality, list_tools, report_outcome, verify_outcome), but 'health' is a bare noun, breaking the pattern. This slight inconsistency is minor and still readable.
With 5 tools, the server is well-scoped for verification tasks: system health check, tool discovery, aggregated quality retrieval, and two outcome recording methods. Each tool has a clear purpose without redundancy.
The tool set covers core verification workflows: recording outcomes and retrieving aggregated quality. However, lacking a tool to retrieve individual verification records or list services creates minor gaps that agents might work around.