Skip to main content
Glama
Sign In
aris-mcp

aris-mcp

by Knuckles-Team
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Aris Get Source Status

aris_get_source_status
Read-onlyIdempotent

Reports the ARIS repository source and configuration state, including mode, API base or AML directory, model count, and whether writes are enabled.

Instructions

Report where the ARIS repository comes from.

Returns mode (live, files, fixture or unconfigured), repository (the API base or the AML directory), model_count (files and fixture modes) and writes_enabled.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "aris_get_source_status"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds genuine value by enumerating the possible modes (live, files, fixture, unconfigured) and the meaning of writes_enabled, which tells the agent this is a capability probe, not just a read.

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 single-sentence purpose followed by a compact field enumeration; nothing is wasted. The field list partially duplicates the existing output schema, which is the only thing keeping it from a top score.

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?

With zero parameters, full annotation coverage and an output schema present, the description needs only to establish purpose and the shape of the answer, which it does. It could go slightly further by noting whether 'unconfigured' mode means subsequent ARIS calls will fail, which is the actionable implication an agent needs.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter detail is needed or missing.

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?

States a specific verb and resource: 'Report where the ARIS repository comes from,' which is clearly a configuration/diagnostic probe. None of the siblings (list_models, get_model, import/export_aml, etc.) perform this function, so the distinction is implicit and easy to infer, though the description never names a sibling to contrast with.

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?

Usage is only implied: an agent can reasonably infer this is a pre-flight check before model operations, but the description never says when to call it, when not to, or what to do with the result. For a zero-parameter diagnostic tool this is a modest gap rather than a harmful one.

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

Deploy Server

Other Tools