Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

scope_review_summary

Read-only

Summarizes an organization's grants by capability and target (tenant/team), counting stale and expiring grants to start quarterly access audits.

Instructions

Aggregate view of every grant in an org — by capability, by target (tenant / team), plus counts of stale and expiring. Starting point for a quarterly audit. Business+ tier (team-level org management).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "org_id": "<org_id>"
    },
    "name": "scope_review_summary"
  }
}

Input Schema

NameRequiredDescriptionDefault
org_idYesThe org whose grants are summarised. Grants older than 90 days count as stale; grants expiring within 30 days count as expiring.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.1

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds useful context beyond them: the aggregation shape, and a Business+ tier / team-level org management requirement that an agent must satisfy before calling. It does not describe response size or ordering, which is a minor gap.

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?

Three short sentences, front-loaded with what is aggregated and in what dimensions. The trailing tier parenthetical is slightly compressed but each sentence carries information; nothing is redundant.

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 single-parameter, read-only, no-output-schema tool, the description sketches the return shape (per-capability, per-target, plus stale/expiring counts) and states the tier gate. Only the absence of any note on result size or pagination keeps it from being fully complete.

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?

There is only one parameter and schema coverage is 100%; the schema itself defines org_id and the 90-day stale / 30-day expiring thresholds. The description's mention of 'stale and expiring' restates what the schema already specifies, so it adds little parameter-level meaning beyond the structured field.

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 ('Aggregate view of every grant in an org') and enumerates the aggregation dimensions (by capability, by target, plus stale/expiring counts). This implicitly separates it from the list_stale_grants / list_expiring_grants / list_scopes siblings, though none is named explicitly.

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?

'Starting point for a quarterly audit' gives a concrete usage context, and the tier note signals a prerequisite. It does not say when to prefer the per-dimension sibling tools (e.g. list_stale_grants for drill-down) or state any exclusions.

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