Skip to main content
Glama

Claimora

by si.claimora
OverviewDiscussionsAdmin

get_updates

List claims whose last_updated is at or after a timestamp.

Use this to read claims that changed after a time you already checked.
Returns claim id, status, evidence strength, and a shortened excerpt.
Example: get_updates(since="2026-01-01T00:00:00Z", domain="ai-ml", limit=20).
Example: get_updates(since="2026-10-01T00:00:00Z", domain="consciousness", offset=20).

Input Schema

NameRequiredDescriptionDefault
limitNoPage size. Example: 20.
sinceYesISO-8601 timestamp. Claims updated at or after this time. Example: 2026-01-01T00:00:00Z.
domainNoRestrict results to one domain. Example: ai-ml.
offsetNoNumber of hits to skip. Example: 0.

Output Schema

NameRequiredDescriptionDefault
pageYes
sinceYes
claimsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedInput schema / properties / domain / description
      Previous value: -"Restrict results to one domain."New value: +"Restrict results to one domain. Example: ai-ml."
    • addedInput schema / properties / domain / examples
      Added value: +[
+  "ai-ml"
+]
    • addedInput schema / properties / limit / description
      Added value: +"Page size. Example: 20."
    • addedInput schema / properties / limit / examples
      Added value: +[
+  20
+]
    • addedInput schema / properties / offset / description
      Added value: +"Number of hits to skip. Example: 0."
    • addedInput schema / properties / offset / examples
      Added value: +[
+  0
+]
    • changedInput schema / properties / since / description
      Previous value: -"ISO-8601 timestamp. Claims updated at or after this time."New value: +"ISO-8601 timestamp. Claims updated at or after this time. Example: 2026-01-01T00:00:00Z."
    • addedInput schema / properties / since / examples
      Added value: +[
+  "2026-01-01T00:00:00Z"
+]
  2. First observed

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description should carry the full burden of behavioral disclosure. It usefully lists the return fields (claim id, status, evidence strength, excerpt) and implies read-only via 'List' and 'read claims', but does not explicitly state safety, permissions, or rate limits. The lack of an explicit read-only declaration is a gap for a tool with zero annotation coverage.

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?

Front-loaded with the core purpose, followed immediately by usage context, return fields, and compact examples. Every sentence earns its place; no redundancy or filler.

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 output schema exists, the description needn't explain return values in detail, but it does so briefly. For a 4-parameter read tool with no annotations, it covers purpose, usage, returns, and examples. It could be more complete by explicitly stating that the operation is read-only, but otherwise it provides sufficient context.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by providing concrete examples that show how parameters combine (since with domain and pagination), which goes beyond the schema's individual parameter examples. This helps an agent understand invocation patterns, though it doesn't explain semantic edge cases (e.g., timezone handling).

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

Purpose5/5

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

States a specific verb (List), resource (claims), and condition (last_updated at or after a timestamp). The usage sentence 'read claims that changed after a time you already checked' further distinguishes it from siblings like query_claims or search_smart by implying incremental updates rather than full searches.

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?

Explicitly says when to use: 'to read claims that changed after a time you already checked.' This gives a clear context for incremental polling, though it does not name specific alternatives or when-not to use. The examples reinforce the intended usage pattern with since, domain, limit, and offset.

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

All Claimora toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources