Skip to main content
Glama

Every edge we hold about one subject

evidence_for
Read-onlyIdempotent

Everything we hold about one subject, as edges, each carrying where it came from. Use it when you need to explain a decision rather than just make one, or to see what is MISSING before you act. Every edge has source, observedAt (when the world was in that state), asOf (when we read it — a fresh read of a stale fact is not a fresh fact), a confidence that names what it is confident IN, its own coverage, and the method that established it. Edges come in three kinds and are NEVER summed: declared is the subject speaking about itself, observed is our reading, derived is arithmetic over the others. Adding them together rebuilds the reputation score this replaces. It infers NO identity: a shared host or funder is reported as exactly that, because being the same party is a conclusion no join supports. lookedForAndMissing lists what we searched for and did not find, so a thin subject never reads as a complete picture. Free.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
subjectYesAn address, or the http(s) URL of an endpoint.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
saysYesWhat the evidence amounts to, in one sentence. Never a verdict: this tool reports edges and leaves the conclusion to the caller.
edgesYesEach with claim, object, kind, source, observedAt, asOf, confidence {value, in}, coverage and method.
kindsNoWhat declared, observed and derived each mean.
countsYesEdges by kind. NOT a score: the three are reported apart and never added.
limitsNoWhat this graph cannot contain. Declared, observed and derived are different kinds of fact and are never added together; `counts` keeps them apart for the same reason.
subjectYesWhat was asked about, read back. Where we resolved it to something else, this is the resolved form.
subjectKindNoWhat we took the subject to BE. `unknown` means we could not classify it, so the empty edge list below is our failure to look rather than a finding about the subject.
lookedForAndMissingNoWhat we searched for and did not find, with why. Listed rather than omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedOutput schema / properties / limits / description
      Added value: +"What this graph cannot contain. Declared, observed and derived are different kinds of fact and are never added together; `counts` keeps them apart for the same reason."
    • addedOutput schema / properties / says / description
      Added value: +"What the evidence amounts to, in one sentence. Never a verdict: this tool reports edges and leaves the conclusion to the caller."
    • addedOutput schema / properties / subject / description
      Added value: +"What was asked about, read back. Where we resolved it to something else, this is the resolved form."
    • addedOutput schema / properties / subjectKind / description
      Added value: +"What we took the subject to BE. `unknown` means we could not classify it, so the empty edge list below is our failure to look rather than a finding about the subject."
  2. Added

TDQS

A4.1/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, open-world, non-destructive, yet the description still adds substantial behavior: the distinctions between source/observedAt/asOf, the three edge kinds that must never be summed, the refusal to infer identity, and the lookedForAndMissing coverage signal. This is exactly the added context the annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then usage, then semantics; each sentence carries meaning. It is dense and slightly sprawling, and some sentences describe output fields that a present output schema already covers, but nothing is idle filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with annotations and an output schema, the description covers when to use it, what each edge means, the no-summing rule, the no-identity-inference rule, missing-data signaling, and cost. Nothing an agent needs to call it correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a single well-documented 'subject' parameter (address or endpoint URL). The description adds no syntax, format, or edge-case guidance beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States what it returns concretely: every edge held about one subject, each carrying provenance. It also implies differentiation by noting it 'replaces' a reputation score, though it does not name a sibling tool explicitly. Clear but the 'edges' framing is jargon that requires inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use conditions: 'when you need to explain a decision rather than just make one, or to see what is MISSING before you act.' It also implies when-not via the warning that edges are never summed or joined into identity. No named alternatives among siblings, so it stops short of 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources