Skip to main content
Glama
williamamed

mcp-polizei

by williamamed

Configuración del tenant

get_tenant_settings

Retrieve the configuration for an app from the current session's tenant. Optionally pass a tenant ID to fetch settings for a different tenant, defaulting to the active one.

Instructions

Devuelve la configuración (settings) de una app para el tenant activo de la sesión (endpoint profile/get-scope-settings, el tenant va como id). Si no se pasa id, usa el tenant activo de la sesión.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoID del tenant (default: tenant activo de la sesión)
appYesNombre de la app

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It conveys that the operation is a read ('Devuelve') and explains the id/tenant resolution behavior, but it does not mention side effects, permissions, or error conditions. This is acceptable for a getter but not exhaustive.

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?

Two sentences with the main action, endpoint, and default behavior. The parenthetical about the endpoint is useful but 'el tenant va como id' is somewhat redundant with the following sentence about the default id. Still compact and front-loaded.

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?

The tool is simple (only two params, both documented) and has no output schema. The description covers the operation, endpoint, and default behavior, which is sufficient for basic invocation. It does not describe the response format, but for a low-complexity getter this is a minor omission.

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 baseline is 3. The description repeats the fact that omitting id uses the active tenant, which reinforces the schema but does not add new semantic meaning. It adds the endpoint context and clarifies the id maps to the tenant, but no more.

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?

The description states a specific verb and resource: 'Devuelve la configuración (settings) de una app para el tenant activo de la sesión.' It also references the exact endpoint (profile/get-scope-settings), and the get/set contrast with the sibling set_tenant_settings makes the purpose unambiguous. No confusion with get_active_tenant, get_dashboard, or list_tenants remains.

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?

The description gives clear context: it applies to the active session tenant and falls back to that tenant when no id is passed. It does not explicitly tell when not to use it or point to alternatives like set_tenant_settings, but the read-only role is evident enough. That places it at 'clear context, no exclusions'.

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