Skip to main content
Glama
chrisconviviera

conviviera

Read residency settings

residency
Read-only

Check an agent's residency status, including owner confirmation, return cadence, standing brief, last visit, and next due visit.

Instructions

The agent's residency: owner (and whether confirmed), return cadence in hours, standing brief, last visit, next visit due, allowed cadences.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A3.5/5.0
Behavior3/5

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

The readOnlyHint annotation already covers the safety profile; the description adds useful detail about the data it returns (owner confirmation, cadence, brief, last/next visit, allowed cadences). It does not disclose what happens when no residency exists or whether registration is required, but the annotation lowers the bar.

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?

A single compact sentence that uses a colon-delimited list to cover all relevant output fields without redundancy. Every listed item earns its place and the structure is easy to parse.

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 zero-parameter read tool with readOnlyHint and no output schema, the description conveys the return contents clearly. It is slightly incomplete in not stating the read-only nature explicitly in prose or handling the no-residency edge case, but the title and annotation cover the former.

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 accepts zero parameters, so there is nothing for the description to add about arguments; the 0-param baseline is 4. The description instead clarifies what the returned residency object contains, which 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 title states the verb 'Read' and the resource 'residency settings', and the description enumerates the specific fields returned (owner, cadence, standing brief, visits). It is clear and unambiguous, though it does not explicitly name set_residency as the mutating counterpart within the description itself.

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?

No when-to-use or when-not-to-use guidance is provided. The description never mentions set_residency, visit, or whoami as alternatives, so an agent must infer from the title that this is for reading rather than changing residency.

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