Skip to main content
Glama
Sign In

UN Charter 1945

by io.arxo
OverviewDiscussionsAdmin

law_process_run

Read-only

How a particular case will run, step by step: a log of {date, attempt?, facts?} is executed frame by frame, and the law of each frame is the law of ITS date. The answer says: which stages have been entered; which attempted transition produced NO legal effect; which duties are violated and which time limits are running; what is available next and WHAT EXACTLY is missing for the rest. The names of transitions come from law_process. Stages entered means "was it ever entered", not "where it is now": the core 0.1 does not compute points of the current state.

Input Schema

NameRequiredDescriptionDefault
stepsYesthe log of the case: [{date, attempt?, time?, decisionTime?, knowledgeTime?, facts: [{predicate, args, provenance}]}]; each fact requires a provenance object ({} is allowed), its fields are optional, and evidence is not required. On an attempted transition `time` is the instant of the event (ISO 8601 with an offset), and by it the bearer takes its place in the history; the decision and knowledge axes of a frame come from the entry, else from the case, else from midnight UTC of the date; every frame names the axes it used and where they came from
packageYesthe instrument
instanceYeswhat is going through the procedure: the number of the lot, of the application, of the case
legalTimeNothe base date (YYYY-MM-DD); the date of a frame is set by the step itself
probeTimeNothe instant of a hypothetical attempt, used to work out the steps available on the last frame; without it the available steps are not computed — the tool does not invent time
procedureNothe procedure, where there is more than one

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / steps / description
      Previous value: -"the log of the case: [{date, attempt?, time?, decisionTime?, knowledgeTime?, facts: [{predicate, args}]}]; on an attempted transition `time` is the instant of the event (ISO 8601 with an offset), and by it the bearer takes its place in the history §161.1 (DECISION-0156); the decision and knowledge axes of a frame come from the entry, else from the case, else from midnight UTC of the date; every frame names the axes it used and where they came from"New value: +"the log of the case: [{date, attempt?, time?, decisionTime?, knowledgeTime?, facts: [{predicate, args, provenance}]}]; each fact requires a provenance object ({} is allowed), its fields are optional, and evidence is not required. On an attempted transition `time` is the instant of the event (ISO 8601 with an offset), and by it the bearer takes its place in the history; the decision and knowledge axes of a frame come from the entry, else from the case, else from midnight UTC of the date; every frame names the axes it used and where they came from"
    • addedInput schema / properties / steps / items
      Added value: +{
+  "properties": {
+    "facts": {
+      "items": {
+        "properties": {
+          "args": {
+            "type": "array"
+          },
+          "predicate": {
+            "type": "string"
+          },
+          "provenance": {
+            "type": "object"
+          }
+        },
+        "required": [
+          "predicate",
+          "args",
+          "provenance"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
  2. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already cover read-only safety, so the description appropriately adds substantive behavioral context: what the answer reports, how stages-entered differs from current state, and that without probeTime the tool does not compute available next steps. It also discloses a significant limitation—that this does not compute points of the current state. It does not explain error behavior, but the additional disclosure is strong.

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

Conciseness3/5

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

The description is front-loaded with its purpose and avoids obvious filler, but it is a dense, run-on paragraph with nested parentheticals and jargon that makes it harder to parse than necessary. Several clauses are useful, but the structure could be clearer and more scannable.

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 six parameters, 100% schema coverage, no output schema, and a complex domain, the description does a substantial job explaining the returned information, the temporal rules, and the tool's limits. It lacks explicit guidance on error cases or when to prefer it over siblings, but it is close to complete for the core behavior.

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 coverage is 100%, so the schema already documents the parameters, including the complex steps structure and the probeTime semantics. The description adds little parameter detail beyond what is in the schema and instead focuses on output and conceptual behavior. This fits the baseline of 3 when the schema does the heavy lifting.

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 opening states a specific function—executing a dated log of case events frame by frame to determine procedural effects—which is more than a restatement of the name. It also distinguishes itself from law_process by noting that transition names come from that tool. However, the purpose is expressed in dense domain jargon ('frame', 'core 0.1') that weakens immediate clarity.

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

Usage Guidelines2/5

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

The description implies that this tool is used when you have a case log to evaluate, but it gives no explicit when-to-use guidance, no when-not conditions, and no comparison against alternatives beyond noting that transition names come from law_process. An agent must infer the selection criteria.

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

All UN Charter 1945 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