Skip to main content
Glama
Sign In

OTP

by io.github.david-steel
OverviewDiscussionsAdmin

Get claims from an operating system

get_claims
Read-only

Get all claims from a specific OOS file. Each claim contains a rule, reasoning (why), failure mode, confidence level, and evidence type. Filter by section, confidence, or evidence type.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "oos_id": "<oos_id>"
    },
    "name": "get_claims"
  }
}

Input Schema

NameRequiredDescriptionDefault
oos_idYesThe OOS file ID to get claims from
sectionNoFilter by section (e.g. 'core_operating_rules', 'failure_patterns', 'coordination_patterns', 'operational_heuristics', 'human_ai_boundary_conditions')
evidenceNoFilter by evidence type
confidenceNoFilter by confidence level

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds value by detailing what each claim contains (rule, reasoning, failure mode, confidence, evidence type), which helps the agent understand the return data. It does not mention pagination or rate limits, but with annotations the bar is lower.

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

Conciseness5/5

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

The description is three sentences, front-loaded with the core purpose, followed by claim structure and filtering options. Every sentence contributes directly to understanding the tool.

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 read-only nature (covered by annotations), a complete parameter schema, and the absence of an output schema, the description provides sufficient context about the return values (claim components). Minor gaps like pagination behavior are not addressed, but overall it is nearly complete for this simple retrieval tool.

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%, so all parameters are documented in the schema. The description's phrase 'Filter by section, confidence, or evidence type' simply mirrors the schema and adds no new semantic detail. Baseline 3 is appropriate.

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 description states a specific verb and resource: 'Get all claims from a specific OOS file.' It clearly differentiates the scope (all claims, not search) but does not explicitly name or distinguish from siblings like search_claims or get_oos.

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

Usage Guidelines3/5

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

It mentions filtering by section, confidence, or evidence type, which implies usage. However, there is no explicit guidance on when to use this tool versus alternatives like search_claims or get_oos, nor are prerequisites or exclusions stated.

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

All OTP toolsInspect
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