FlowState Hosted

manage_skills

The connected app's own learned skills, checkpoints and metrics: how the AI works, not project facts (those go in log_work). learn: save a skill. list: a project's and global skills. confirm: one more session where it held (promoted after 3 at a 0.8 rate). save_state / get_state: a checkpoint. log_metric / list_metrics: scores. Reads: list, get_state, list_metrics; the rest only add rows or counts. Returns rows.

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": {
      "action": "<action>"
    },
    "name": "manage_skills"
  }
}

Input Schema

Name	Required	Description
`model`	No	Model name if known. Never guess.
`skill`	No	learn: what was learned (required).
`action`	Yes	The operation; see the tool description.
`context`	No	learn: when it applies. log_metric: where it was scored.
`outcome`	No	log_metric: what happened.
`project`	No	Project name or id. Required except for list and list_metrics; list adds global skills.
`skill_id`	No	confirm: the skill's id (required).
`key_facts`	No	save_state: facts to keep.
`tool_name`	No	learn: the related tool. list: filter.
`skill_type`	No	learn (required) / list (filter): the kind of skill.
`metric_type`	No	log_metric (required) / list_metrics (filter): which metric.
`action_taken`	No	log_metric: what was done.
`focus_summary`	No	save_state: what the session was doing.
`promoted_only`	No	list: only promoted skills.
`pending_decisions`	No	save_state: decisions not made yet.
`active_problem_ids`	No	save_state: problem ids in progress.
`effectiveness_score`	No	log_metric: score from 0.0 to 1.0.
`active_component_ids`	No	save_state: component ids in progress.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4/5.0

Behavior4/5

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

With annotations only declaring tool-level readOnlyHint=false and destructiveHint=false, the description adds genuinely useful per-action disclosure: list, get_state, and list_metrics are reads while the rest "only add rows or counts," and it states the promotion rule (3 sessions at a 0.8 rate). It does not say whether learn deduplicates an existing skill or how confirm behaves when the threshold is not met, so the mutation semantics are not fully closed.

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?

Identity and sibling exclusion are front-loaded, then actions are listed telegraphically with no filler. The compression occasionally costs clarity ("confirm: one more session where it held" is terse to the point of needing inference), but every line carries information.

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

Completeness3/5

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

For an 18-parameter, seven-action tool with no output schema, the description covers each action's intent but leaves the return shape at "Returns rows" and never describes what get_state yields. A checkpoint read tool with no output schema arguably needs a sentence about what comes back, so the definition is adequate rather than 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?

Schema coverage is 100% across 18 parameters, so the schema already carries per-parameter meaning and the baseline applies. The description adds domain semantics for confirm (one more session, promotion after 3 at a 0.8 rate) that the schema does not encode, but it does not clarify how the many optional save_state fields interact or which fields are required per action beyond what the schema states.

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 first sentence names the resource precisely (the connected app's own learned skills, checkpoints, and metrics) and explicitly contrasts it with project facts, which are routed to log_work. Each of the seven actions is then mapped to a one-line purpose, so an agent can tell this apart from siblings like manage_memory or manage_rules without opening the schema.

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 a clear when-to-use boundary against log_work ("how the AI works, not project facts") and explains the intent of each action. It stops short of naming when to prefer this over manage_memory or manage_rules, which is the main remaining ambiguity in a crowded sibling set.

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

All FlowState Hosted tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?