Read a subject's evidence graph (free): how many times it has been verified through LAIN, when it was last checked, and rolling findings. The graph is built one paid resolution at a time, so it may be empty for a subject nobody has checked yet.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes |
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, the description carries the full transparency burden. It discloses that the operation is read-only ('Read'), free, and that the graph may be empty because it is built incrementally via paid resolutions. This adds meaningful context about the tool's behavior and limitations, though it doesn't cover error states or authentication.
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: the first clearly states the action and data returned, the second adds a relevant caveat about empty graphs. It is concise, well-structured, and contains no 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?
Despite the tool's simplicity, the description lacks critical parameter semantics and the absence of an output schema means the agent cannot infer the return format beyond the listed data points. The note about empty graphs helps but is insufficient for confident invocation without knowing what 'subject' should be.
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 defines one required string parameter 'subject' with no description, and the description does not explain what constitutes a valid subject (e.g., ID, name, or format). With 0% schema description coverage and no param info in the description, the agent has no guidance on how to populate this parameter correctly.
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 reads a subject's evidence graph and specifies the exact data it returns (verification count, last checked, rolling findings). It also distinguishes it as a free read operation, which contrasts with sibling tools that involve funding or requesting capabilities.
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 when you need a subject's verification status, and mentions 'free' and the possibility of an empty graph for unchecked subjects. However, it does not explicitly say when to use this tool over alternatives like resolve_confidence or discover_capabilities, and offers no exclusions or comparison.
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 targets a distinct operation—discovery, funding, job polling, receipt minting, capability purchase, confidence resolution, graph reading, and verification. No two tools overlap in purpose, and the detailed descriptions make selection unambiguous.
Most tools follow a verb_noun pattern (discover_*, fund_opportunity, get_job, get_sample_receipt, request_capability, resolve_confidence), but subject_evidence_graph is a noun phrase and verify is a bare verb, creating minor inconsistency.
With 9 tools, the server is well-scoped, covering discovery, funding, execution, and verification without redundancy or bloat.
The tool surface covers the full evidence lifecycle: discover opportunities, fund them, poll jobs, mint receipts, request capabilities, resolve confidence gaps, read evidence graphs, and verify receipts. No obvious operational gaps.
