Deterministically explain what an Obelisk Rating number means: its trust band, how the public scan scores, and what typically moves a score. Pure function of the number — no data is read.
| Name | Required | Description | Default |
|---|---|---|---|
| rating | Yes | A 0-100 Obelisk Rating, e.g. from scan_trust or get_org_rating. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses key behavioral traits: it is 'deterministic', a 'pure function', and 'no data is read'. With no annotations provided, the description carries full responsibility for transparency, and it fully meets that burden by revealing the tool is safe, idempotent, and side-effect-free.
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 extremely concise (two sentences) and front-loaded: the first sentence immediately states the tool's purpose and what it covers, the second adds a critical behavioral qualifier. Every sentence is essential with zero waste.
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, low complexity), the description is complete. It fully explains what the tool does, what it covers, and its side-effect-free nature. No additional information is needed for this deterministic explanation tool.
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 already describes the rating parameter with 100% coverage (type, range, and examples). The description adds value by explaining the semantics of the output (trust band, scan scores, movers) and reinforcing that the number is a 0-100 Obelisk Rating, which complements the schema's examples.
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 'explain', the resource 'Obelisk Rating number', and what the explanation covers: its trust band, public scan scores, and what moves a score. It distinguishes itself from siblings like get_org_rating and scan_trust by emphasizing that this is a pure, deterministic explanation of the rating value itself.
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 states 'Pure function of the number — no data is read', indicating when to use this tool (to understand a rating number without side effects or data retrieval) and implicitly that alternatives like scan_trust or get_org_rating should be used when actual data reads are needed.
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.
Every tool has a distinct concern: explaining ratings, reading gate status, fetching proofs, looking up org ratings, scanning URLs, checking transparency heads, and verifying proofs/tokens. Even the proof-related tools are cleanly separated into read (get_agent_proof) versus verify (verify_agent_run_proof).
Most tools follow a clear snake_case verb_noun pattern: explain_rating, scan_trust, get_org_rating, verify_token, verify_agent_run_proof. However, gate_status and transparency_head are noun phrases rather than command-style names, which is a minor inconsistency.
Eight tools is a well-scoped set for a read-only trust and verification server. Each tool covers a meaningful capability with no redundant or superfluous entries.
The core domain is covered well: rating explanation, rating retrieval, trust scanning, gate status, agent proofs, run op and token verification, and transparency anchoring. The main gaps are convenience functions like listing organizations or resolving proof IDs, but these are not essential to the primary workflow.