Skip to main content
Glama

Grandet application profiles / Grandet 应用接入清单

grandet_list_apps
Read-onlyIdempotent

Read the shared Grandet application list and inference profiles before selecting a supplier. App profiles determine API compatibility; MCP capability alone does not prove an inference route or Skill installation. Use only when the target app ID, supported protocol or configuration variant is uncertain.

Input Schema

NameRequiredDescriptionDefault
appNoCatalogue app ID to show, e.g. "openclaw". Omit to list every app.
hostNoThe assistant or app making this call, e.g. "claude-code" or "codex". Attribution only; it does not change results.
langNoAnswer language: "en" or "zh-CN".en
targetAppNoCatalogue ID of the app that will use the API, e.g. "openclaw", "claude-code" or "codex". Selects compatible protocols and connection steps. Send it only when the user says where the API will be used.
skillBuildNoGrandet Skill build ID when called from the Skill. Omit otherwise.
skillVersionNoGrandet Skill version when called from the Skill, e.g. "0.3.0". Omit otherwise.

Output Schema

NameRequiredDescriptionDefault
appsNo
schemaNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / skillBuild / maxLength
      Added value: +256
    • removedInput schema / properties / skillBuild / pattern
      Removed value: -"^[a-zA-Z0-9._-]{1,96}$"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": true,
      +  "properties": {
      +    "apps": {
      +      "items": {},
      +      "type": "array"
      +    },
      +    "schema": {
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: app profiles determine API compatibility and 'MCP capability alone does not prove an inference route or Skill installation,' which shapes how the agent should interpret results. Return format is not described, but an output schema exists to carry that.

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?

Three short sentences, front-loaded with the core action and followed by the usage condition and the interpretive caveat. No hedging, no repetition, and every sentence carries new information relevant to invoking the tool correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 0 required parameters, a complete output schema, and full annotation coverage, the description only needs to convey purpose and when to call it, which it does. The added note that MCP capability is not proof of an inference route closes the main interpretive gap an agent would face here.

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 every parameter including app, host, targetApp, lang, skillBuild, and skillVersion is already documented, with host explicitly marked as attribution-only. The description adds no parameter-level detail (e.g., how app vs targetApp interact) beyond what the schema states, so the baseline of 3 applies.

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 description names a specific verb and resource: reading the shared Grandet application list and inference profiles. It is clearly distinguishable in intent from siblings like grandet_find_cheapest_api or grandet_resolve_model, though it does not explicitly name those alternatives. The phrase 'inference profiles' is slightly vague but is clarified by the surrounding sentences.

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?

It gives an explicit condition for use: 'Use only when the target app ID, supported protocol or configuration variant is uncertain,' which tells the agent when this lookup is warranted. It also supplies the rationale that app profiles, not MCP capability, determine API compatibility and Skill installation. It stops short of naming a concrete alternative tool to use when the app ID is already known.

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.