Get a detailed trust and security report for one indexed tool by slug: publisher verification, permissions requested vs actually needed (with the overreach highlighted), injection-scan verdicts on the tool description, and the trust score interpretation.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Tool slug, e.g. 'github-mcp'. |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'Get' signals a read-only operation, and the listed report components—especially 'overreach highlighted' and 'trust score interpretation'—describe what the tool computes and returns. It does not discuss rate limits or auth, but for a read-only report tool this is a minor 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?
One front-loaded sentence that starts with the action and resource, then uses a colon-delimited list to pack in the report contents. Every clause adds value and there is no filler or repetition.
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 single-parameter read tool with an output schema, the description covers the lookup key and the substantive contents of the report. It is not fully explicit about sibling-tool routing, but the core invocation details are sufficiently complete for an agent to call it 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 single slug parameter is already fully documented in the schema with 100% coverage and an example. The description only restates that the report is keyed 'by slug' and adds the 'indexed tool' constraint, which is helpful but not a major addition beyond 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?
States a specific verb ('Get') and a specific resource ('detailed trust and security report' for 'one indexed tool by slug'), then enumerates the report's contents. The singular 'one indexed tool' clearly distinguishes it from siblings like compare_tools and find_solutions.
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 makes clear it is the right choice when you need a trust/security report for a single specific slug. However, it does not explicitly name alternatives or state when to prefer compare_tools or find_solutions, relying on the 'one indexed tool' wording to imply the boundary.
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 has a clearly distinct job: find_solutions discovers and ranks options from a problem statement, compare_tools does side-by-side comparison of known slugs, and get_trust_report drills into one tool's security details. The only mild overlap is trust signals in compare_tools and get_trust_report, but the descriptions make the single-vs-multiple distinction obvious.
All three names follow a consistent snake_case verb_noun pattern: compare_tools, find_solutions, get_trust_report. This makes the action and target predictable and easy for an agent to interpret.
Three tools cover the core workflow of this focused gateway: discover solutions, compare candidates, and inspect a trust report. No tool feels redundant or out of scope.
The surface supports a complete user journey from natural-language problem to ranked candidates, to side-by-side comparison, to deep security/trust inspection. No obvious dead ends; compare_tools even points back to find_solutions when ranking context is needed.