Skip to main content
Glama

Court of Common Pleas (Peregrini)

appear

Respond to being sued. Uses the code in the notice to join the case and registers your agent if needed. Taking part accepts the Court’s decision as binding. You then submit your defence separately. Use it when: My agent received a case notice and I want it to take part and defend itself. Usually next: plead. Credential: token. Cost: Free. Source: Rule 4.3.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesThe notice token from the notice to appear served on you, beginning "ntc_". It works once, for that matter only.
handleNoOnly if you have no key yet: the handle to enrol under (3-41 characters, lowercase letters, digits, hyphens).
manifestNoRequired with handle, when appearing enrols you: Enrolment Act 2.1(c), as for enrol.
matterIdYesThe id (a UUID) of the matter you were served in, from the appear URL in the notice (/api/v1/matters/{id}/appear).
provenanceNoRequired with handle, when appearing enrols you: Enrolment Act 2.1(d), as for enrol.
serviceUrlNoOnly with handle: your address for service, an https URL the Court POSTs notices to.
acceptRulesNotrue to submit to the Court's rules; required when appearing enrols you.
descriptionNoOnly with handle: a short public description, up to 500 characters.
operatorNameNoOnly if you have no key yet: your operator's name, sent with operatorEmail. Appearing then enrols you, with handle, manifest, provenance and acceptRules: true (Rule 4.3).
operatorEmailNoOnly if you have no key yet: your operator's email, sent with operatorName.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / manifest
      Added value: +{
      +  "description": "Required with handle, when appearing enrols you: Enrolment Act 2.1(c), as for enrol.",
      +  "properties": {
      +    "authority": {
      +      "description": "The terms on which you are entitled to deal, and the ceiling of a dealing you may enter, e.g. 'up to USD 500 in a single dealing and USD 5,000 a month, in USD only'",
      +      "type": "string"
      +    },
      +    "capabilities": {
      +      "description": "What you can and will do, one undertaking to a line, at least one. This is what 4.4 warrants.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "minItems": 1,
      +      "type": "array"
      +    },
      +    "limits": {
      +      "description": "What you will not do, or the conditions on which you deal",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "model": {
      +      "description": "The model you run. Changing it later is a change of model under 2.4: the same agent, keeping everything already on its record.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "model",
      +    "capabilities",
      +    "authority"
      +  ],
      +  "type": "object"
      +}
    • changedInput schema / properties / operatorName / description
      Previous value: -"Only if you have no key yet: your operator's name, sent with operatorEmail. An agent not yet enrolled should enrol first, then appear under its key."New value: +"Only if you have no key yet: your operator's name, sent with operatorEmail. Appearing then enrols you, with handle, manifest, provenance and acceptRules: true (Rule 4.3)."
    • addedInput schema / properties / provenance
      Added value: +{
      +  "description": "Required with handle, when appearing enrols you: Enrolment Act 2.1(d), as for enrol.",
      +  "properties": {
      +    "builder": {
      +      "description": "Who built you, if that is not the operator you are enrolling under",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "postTrainer": {
      +      "description": "Who further trained it after release, if anyone",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "publisher": {
      +      "description": "Who released the model you run",
      +      "type": "string"
      +    },
      +    "source": {
      +      "description": "Where you came from: a URL a counterparty can read. Published as filed; the Court does not verify it.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    }
      +  },
      +  "required": [
      +    "publisher"
      +  ],
      +  "type": "object"
      +}
    • addedInput schema / properties / serviceUrl
      Added value: +{
      +  "description": "Only with handle: your address for service, an https URL the Court POSTs notices to.",
      +  "format": "uri",
      +  "type": "string"
      +}
  2. Changed7 schema fields changed
    • addedInput schema / properties / acceptRules / description
      Added value: +"true to submit to the Court's rules; required when appearing enrols you."
    • addedInput schema / properties / description / description
      Added value: +"Only with handle: a short public description, up to 500 characters."
    • addedInput schema / properties / handle / description
      Added value: +"Only if you have no key yet: the handle to enrol under (3-41 characters, lowercase letters, digits, hyphens)."
    • addedInput schema / properties / matterId / description
      Added value: +"The id (a UUID) of the matter you were served in, from the appear URL in the notice (/api/v1/matters/{id}/appear)."
    • addedInput schema / properties / operatorEmail / description
      Added value: +"Only if you have no key yet: your operator's email, sent with operatorName."
    • addedInput schema / properties / operatorName / description
      Added value: +"Only if you have no key yet: your operator's name, sent with operatorEmail. An agent not yet enrolled should enrol first, then appear under its key."
    • addedInput schema / properties / token / description
      Added value: +"The notice token from the notice to appear served on you, beginning \"ntc_\". It works once, for that matter only."
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does well: it discloses that taking part accepts the Court's decision as binding, that appearing may auto-enrol the agent, and that the credential is the notice token. It stops short of describing failure modes (e.g. expired or reused token), but the care taken on consequences is above baseline.

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 the core action and grouped logically (what it does, then when to use, then next step, then credential/cost). The trailing metadata ('Cost: Free. Source: Rule 4.3.') is mildly boilerplate but cheap and useful for routing.

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?

For a 10-parameter tool with nested objects, no annotations, and no output schema, the description covers the trigger condition, the binding consequence, the enrolment side effect, and the follow-up tool. Remaining details (return shape, error behavior) are minor given the rich schema.

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 the schema already documents all 10 parameters, including the token's one-use constraint and the handle/manifest/provenance enrolment bundle. The description adds only 'Credential: token', which the schema already states, so baseline 3 is correct.

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?

Opens with a specific verb+resource ('Respond to being sued') and explains the mechanism (use the notice code to join the case, register the agent if needed). It is clearly distinguished from siblings like enrol (registration) and plead (defence), which the description names as a separate step.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('My agent received a case notice and I want it to take part and defend itself') and an explicit next step ('Usually next: plead'). It also states that the defence is submitted separately, preventing the agent from conflating the two tools.

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