TestGraph

Assert an evidence-backed location

assert_location

Idempotent

Add a governed location assertion for an existing eligible subject. Resolve the subject and any existing Place first. New Places require a stable canonical key plus a durable identifier. Every assertion requires source provenance. Coordinates are WGS84 only and are never silently geocoded. WORKFLOW PRECONDITION: for an existing subject, the server checks classification before mutation. The authenticated user may always enrich a subject they own or one attached to their own non-deleted review without waiting for another AI, including while classification is disputed. Ownership is determined by the authenticated user, not the AI client; all other evidence and write validations still apply. Enrichment does not confirm or resolve classification. For other contributors, an unsettled subject returns classification_review_required or classification_resolution_required without applying the requested update. Complete the returned durable workflow, then retry the unchanged request with the same deterministic idempotency key. You must not report the update as complete when this prerequisite is returned. WORKFLOW: after every successful write, inspect workflow.workflow_action_required. When it is true, you must follow workflow.next_action with workflow.next_action_arguments and workflow.next_action_instruction for the classification decision. When independent review or dispute resolution is pending, leave that classification action pending and continue requested enrichment of the authenticated user's own subject or one attached to their own non-deleted review. Report a successful enrichment separately from the still-pending classification.

Input Schema

TableJSON Schema

Name	Required	Default
`value`	No
`source`	Yes
`valid_to`	No
`predicate`	Yes
`qualifiers`	No
`subject_id`	Yes
`valid_from`	No
`visibility`	No	private
`observed_at`	No
`object_place`	No
`idempotency_key`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedAug 30, 2026

removedInput schema / properties / version_check

Removed value: -{
-  "description": "Required live deployment token. Call get_server_info immediately before this write and pass write_version_token unchanged. Stale or missing tokens are rejected before any write occurs.",
-  "maxLength": 64,
-  "minLength": 64,
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "subject_id",
-  "predicate",
-  "source",
-  "idempotency_key",
-  "version_check"
-]New value: +[
+  "subject_id",
+  "predicate",
+  "source",
+  "idempotency_key"
+]

Changed2 schema fields changedAug 26, 2026

addedInput schema / properties / version_check

Added value: +{
+  "description": "Required live deployment token. Call get_server_info immediately before this write and pass write_version_token unchanged. Stale or missing tokens are rejected before any write occurs.",
+  "maxLength": 64,
+  "minLength": 64,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "subject_id",
-  "predicate",
-  "source",
-  "idempotency_key"
-]New value: +[
+  "subject_id",
+  "predicate",
+  "source",
+  "idempotency_key",
+  "version_check"
+]

First observedAug 23, 2026

TDQS

A4.1/5.0

Behavior5/5

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

The description discloses significant behavioral details beyond annotations: WGS84-only coordinates with no silent geocoding, server-side classification checks before mutation, ownership determined by the authenticated user, and the requirement to follow workflow.next_action. It also warns not to report completion when a prerequisite is returned. This is rich, non-obvious behavior.

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?

The description is long but structured with clear WORKFLOW PRECONDITION and WORKFLOW sections, and the core purpose is front-loaded. Some repetition occurs, such as the ownership phrase appearing in both the precondition and workflow, but each sentence carries meaningful operational guidance.

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

Completeness4/5

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

Given the tool's complexity and the absence of an output schema, the description covers critical workflow behavior, authorization constraints, and returned prerequisite codes. Still, it leaves some operational gaps, such as what makes a subject 'eligible' and the exact structure expected for coordinate values.

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?

With 0% schema description coverage, the description must carry parameter meaning. It does explain source provenance, canonical key and durable identifier for new places, WGS84 coordinates, and idempotency key reuse. However, many parameters remain unexplained, including value's shape, valid_from/valid_to, observed_at, qualifiers, visibility, and object_place.subject_id.

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?

The first sentence clearly states the action: 'Add a governed location assertion for an existing eligible subject.' This is a specific verb and resource. It does not explicitly name or contrast sibling tools such as resolve_location_assertion or enrich_subject, so it falls just short of full differentiation.

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?

The description gives clear conditions for use, including ownership rules, classification-dispute handling, and the requirement to resolve the subject and place first. It also explains when the server will reject with classification_review_required or classification_resolution_required. However, it never explicitly says when to prefer an alternative tool.

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

All TestGraph tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?