managed-agent-control-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource (agent, environment, vault, memory store, session) and action (list, get, start, etc.). No two tools serve overlapping purposes; even session_archive and session_delete are clearly differentiated by their effects.
Naming Consistency5/5
Tool names follow a consistent noun_verb pattern (e.g., agent_get, session_start), all lowercase with underscores. There is no mixing of conventions across the tool set.
Tool Count5/5
17 tools cover the domain of managed-agent control without being excessive. Each tool serves a needed function, and there are no redundant or trivial tools.
Completeness4/5
The tool set covers the full session lifecycle (start, message, observe, interrupt, respond, archive, delete). While resource management (e.g., create/update for agents, environments) is missing, it is likely out of scope, making the surface complete for its control purpose.
Average 4.2/5 across 17 of 17 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It mentions the returned data (full configuration with packages, networking) but fails to disclose if the operation is read-only, requires authentication, or any side effects.
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?
The description is a single, front-loaded sentence with no unnecessary words. It effectively communicates the tool's action and target.
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?
Given the tool is simple with one parameter and has an output schema, the description covers the main purpose. However, it lacks information on error handling, missing environment cases, or any prerequisites.
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?
The schema's environment_id parameter lacks any description. The description adds the hint 'by `env_*` id', implying the id format, which provides some guidance beyond the schema's bare type definition.
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 clearly states the tool retrieves a single environment's full configuration, specifying the resource as 'environment' and mentioning included components like packages and networking. It distinguishes from siblings such as environment_list which presumably lists environments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching a specific environment by its id, contrasting with environment_list. However, it does not explicitly state when to use this tool versus alternatives or provide any usage constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It discloses permanence and the running session restriction, but lacks details on side effects, permission requirements, or irreversibility beyond 'permanently'. Adequate but not rich.
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?
The description is two sentences with no extraneous text. It front-loads the core action and adds a critical constraint. Every sentence provides essential 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?
The tool has an output schema, so return values may be covered there. However, for a destructive tool, the description could mention confirmation behavior or idempotency. It is adequate but missing parameter details, making it somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate but does not. It offers no guidance on the session_id parameter, such as format, origin, or how to obtain a valid ID. The description solely describes the action without parameter context.
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 clearly states the tool's action: permanently delete a session including history and sandbox. It also distinguishes from siblings by mentioning the constraint against running sessions, which differentiates it from session_archive or session_interrupt.
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 explicitly says 'Cannot delete a running session,' providing a clear when-not-to-use condition. However, it does not discuss alternatives like session_archive for archiving instead of deleting, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral transparency. It mentions the tool returns details but does not disclose whether it is read-only, potential error conditions (e.g., ID not found), or any side effects. The description is adequate for a simple getter but could be more explicit.
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?
The description is a single, concise sentence of 14 words. It is front-loaded with the action and resource, and efficiently lists the returned fields. No superfluous information.
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?
Given the simplicity of the tool (one parameter, output schema present), the description covers the essential purpose and input. It does not include usage context or error handling, but the output schema presumably documents return fields. Minor gap in not describing potential errors.
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?
The input schema has 0% description coverage; the parameter is just a string. The description adds value by specifying the format ('memstore_*' id), but it does not provide examples or constraints beyond that. For a single parameter, this is acceptable but not comprehensive.
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 clearly states the action ('Get'), the resource ('one memory store's details'), and the identifier type ('by `memstore_*` id'). It also lists the returned fields (name, description, timestamps), distinguishing it from sibling tools like 'memory_store_list'.
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 implies usage for retrieving a specific memory store via its ID. The presence of a sibling 'memory_store_list' naturally differentiates between list and single-item retrieval. However, it does not explicitly state when to prefer this tool over alternatives or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses key traits: stops new events, preserves history, and notes reversibility. Lacks details on existing event behavior and permissions.
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?
Single sentence with no filler, front-loaded with key information. Every word serves a purpose.
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?
Output schema exists, so return value explanation not needed. Description covers purpose, key behavior, and reversibility. Lacks prerequisites or error details but sufficient for simple tool.
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 0% but single required parameter (session_id) is self-explanatory. Description adds no parameter details, but schema clarity compensates partially.
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?
Description clearly states verb 'archive', resource 'session', and specifies behavior: stops new events, keeps history, reversible-ish. Distinguishes from sibling session_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for archiving but lacks explicit when-to-use vs alternatives like session_delete or session_interrupt. No when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses status meanings and the special idle+requires_action state, adding valuable behavioral context beyond schema.
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?
Two concise sentences: first states purpose, second explains status values and cross-reference to another tool. No unnecessary words.
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?
Has output schema, so return details are covered. Description explains status values adequately. Could mention token usage details, but sufficient for a simple retrieval tool.
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?
Only one parameter (session_id) with 0% schema description coverage. Description does not elaborate on the parameter, but the name is self-explanatory. No additional meaning added.
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?
Clearly states the tool gets a session's status and token usage, lists specific status values, and explains the 'requires_action' condition. Differentiates from siblings like session_respond.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use of session_respond when idle with requires_action, but lacks explicit when-to-use or when-not-to-use guidance compared to siblings like session_events or session_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that it sends a user.interrupt and the effect of then_message, but no annotations exist to cover side effects, permissions, or error cases. Lacks full behavioral disclosure for a mutation tool.
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?
Two concise sentences with no waste. First sentence states purpose, second adds key behavioral detail. Front-loaded and efficient.
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?
Covers main interrupt function and optional redirect. With output schema available, omission of return values is acceptable. Could mention whether session continues or agent terminates, but overall complete for the tool's scope.
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?
With 0% schema description coverage, the description compensates by explaining both parameters: session_id (implied by 'running agent') and then_message (explicitly explained with behavior). Adds meaning beyond schema.
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?
Description clearly states verb 'Interrupt' and resource 'running agent', and distinguishes from sibling tools like session_message or session_respond which are for sending messages without interrupting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains the interrupt-and-redirect pattern but does not explicitly compare to alternatives or state when not to use it. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden for behavioral traits. It correctly implies mutation ('send') but is non-destructive. It adds the key behavioral detail about polling session_events to see the agent's response. No contradictions with annotations exist.
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?
The description is two sentences long, front-loaded with the main action, and every clause adds value. It is efficient and well-structured with no wasted words.
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?
Given the tool's simplicity and the existence of an output schema, the description is largely complete. It covers the primary input, the expected follow-up action (polling events), and its role relative to siblings. Minor omissions like error conditions or rate limits do not significantly harm completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. However, it adds no meaning to the two parameters (session_id, text) beyond their names. It does not specify expected format, length, or examples, leaving the agent guessing about the text parameter's content.
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 clearly states the tool's purpose: 'Send a user message to the agent — start work, reply, or continue a turn.' It specifies the verb (send) and the resource (user message to the agent), and distinguishes from siblings like session_start (new session) and session_respond (specific reply).
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 explicit usage guidance: 'Use to give the agent a new instruction or to resume an idle session.' It also advises the next step: 'After sending, OBSERVE by polling session_events.' While it does not explicitly list when not to use or alternatives, the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions pagination via `next_page` token and the fields returned, but does not explicitly state that the operation is read-only or idempotent. While the verb 'List' implies safety, the description could be more transparent about behavior.
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?
The description is concise with five sentences, each adding value. It front-loads the purpose and then provides usage guidance without unnecessary detail. No fluff.
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?
Given the existence of an output schema, the description covers the essential aspects: the summary fields, pagination, and the linkage to `agent_get`. It provides a complete context for using this tool in a workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints at pagination ('Page via the returned `next_page` token') but does not explain that `limit` controls page size or that `page` is a token. The parameters remain poorly described.
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 clearly states the tool's purpose: 'List managed agents (summaries: id, name, model, description, metadata).' It uses a specific verb ('List') and resource ('managed agents'), and distinguishes itself from the sibling `agent_get` by noting that this tool returns summaries while `agent_get` provides full config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Find an `agent_*` to run (unless the user gave one). Read each agent's name/description/metadata to understand what it does... Use `agent_get` for full config before starting.' This tells when to use this tool and when to use a sibling, and outlines a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without any annotations, the description carries the full burden of explaining behavior. It discloses that it supports pagination via a next_page token and returns id + status for each session. It does not mention idempotency or side effects, but as a listing operation, these are minimal. The description provides sufficient behavioral context beyond a simple 'list sessions'.
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?
The description is extremely concise: two sentences that cover the purpose, filters, and pagination detail. It is front-loaded with the main action and uses no wasted words. Every sentence adds value.
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?
Given the tool has 4 parameters, no annotations, and an existing output schema, the description covers the essential aspects: purpose, filters, and pagination. It is missing details like error handling or what happens with empty results, but the output schema likely covers return structure. Overall, it is sufficiently complete for a simple listing tool.
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?
The schema coverage is 0%, so the description must compensate. It explains the statuses parameter with an example, and the page parameter through pagination context. However, the limit parameter is not described, and the agent_id is only briefly mentioned as optional. The description adds value for most parameters but is incomplete for limit, which lowers the score from a 4 to a 3.
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 clearly states 'List sessions' with the specific verb 'list' and resource 'sessions', and it explains optional filters by agent_id and statuses. It distinguishes from sibling tools like session_get which retrieves a single session, and other session actions. The purpose is unambiguous.
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 provides clear context for when to use this tool: to list sessions with optional filtering and pagination. It implicitly excludes actions like getting a single session (session_get) or mutating sessions (session_delete). However, it does not explicitly state when not to use it or compare to alternatives, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the gate behavior and workflow, but does not mention side effects, auth needs, or what happens after approval/denial.
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?
Concise: main action in first sentence, then precise usage conditions. No wasted words, well-structured.
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?
Given output schema exists, description doesn't need return values. Covers trigger, parameters, and action. Lacks some behavioral details but sufficient for a gate tool.
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?
Schema coverage is 0%, so description compensates by explaining tool_use_id (blocking event id), result (allow/deny), and deny_message (optional explanation). session_id is not explained but self-explanatory.
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 clearly states the tool's purpose: 'Approve or deny a tool call the agent is waiting on (a permission policy gate).' It uses specific verbs and resource, and distinguishes from siblings like session_get and session_interrupt.
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 explains when to use: when session_get shows 'idle' with stop_reason 'requires_action', and specifies the required parameters. It lacks explicit when-not-to-use or alternatives, but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the transparency burden. It discloses that secret values are never returned and that the tool is metadata-only. It also adds context about how Anthropic handles secrets. However, it does not cover error behavior (e.g., vault not found) or authorization requirements.
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?
The description is two sentences long, front-loads the main action, and every sentence adds value. There is no redundant or filler content, maintaining a high signal-to-noise ratio.
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?
Given the existence of an output schema (handling return values), the description covers purpose, parameter format, behavioral constraints, and a clear use case. For a simple get-by-id tool, this is comprehensive and leaves little ambiguity.
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?
The input schema has a single parameter 'vault_id' with no description (0% coverage). The description adds that the id follows the 'vlt_*' pattern, which provides some semantic guidance beyond the schema's 'string' type. However, it does not elaborate on how to obtain the id or its format constraints.
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 clearly states that the tool gets one vault's details by vault_id, specifies the returned fields (display name, metadata, timestamps), and distinguishes itself from vault_list by focusing on a single vault. The purpose is specific and unambiguous.
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 provides a clear use case: 'to confirm the vault is the one you want before attaching it.' It implies when to use this tool (when you need to verify a vault) and indirectly suggests that vault_list is the sibling for listing. However, it does not explicitly mention when not to use it or give alternative tools beyond context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavioral traits: the tool's output is summaries, and incorrect vault selection causes server failures. Although no annotations exist, it adds significant safety context. Lacks explicit 'read-only' statement but implied by listing.
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 sentences, front-loads purpose, follows with critical usage guidance. Every sentence adds value; no fluff.
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?
Covers purpose, critical selection dependency, and pagination. With an output schema present, return value details are not required. Minor gap: could clarify parameter interaction, but context is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, meaning parameters (limit, page) are not described. The description only hints at pagination via 'next_page' but does not explain how parameters work or their defaults. Insufficient compensation.
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 clearly states the tool lists credential vaults and specifies the returned fields (summaries: id, display_name, metadata). It effectively distinguishes itself from sibling tools like vault_get by implying a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the tool: agents requiring auth must select the correct vault. It warns about consequences of attaching the wrong vault and mentions pagination via 'next_page', offering actionable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses read-only listing behavior, output shape (summaries), and pagination mechanism. Does not detail authentication or rate limits, but covers essential operational info.
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 well-structured sentences. First sentence states purpose with output fields. Second and third provide crucial usage guidance and warnings. No fluff, directly actionable.
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?
Given output schema exists, description sufficiently covers return fields and selection guidance. Lacks detail on pagination token format and any ordering, but remains adequate for a list tool with sibling 'environment_get' for deeper detail.
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 has 0% description coverage. The description partially compensates by mentioning 'Page via next_page' for pagination, but does not explain the 'limit' parameter or the format of 'page'. Adds marginal value beyond schema.
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 clearly states the tool lists sandbox environments and specifies the summary fields (id, name, description, metadata). It distinguishes from sibling 'environment_get' by focusing on listing multiple environments and warns about selection importance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use the tool: for selecting an environment to start a session. It warns against picking the first result and instructs matching via name/description/metadata. Also mentions pagination with 'next_page', giving clear context on usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses listing behavior, pagination support, and warns of destructive consequences if wrong store is attached. However, it does not explicitly state read-only nature.
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?
Triple-sentence description is concise, front-loads purpose, and adds critical context without wasted words. Every sentence earns its place.
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?
Given the presence of output schema (handles return values), the description covers listing, pagination, and usage context fully. Warnings about store attachment provide necessary completeness for safe use.
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 has 2 optional parameters (limit, page) with 0% coverage. Description mentions pagination via 'next_page' but does not explain limit or parameter types. Partially compensates but lacks full parameter documentation.
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 clearly states the verb 'List' and resource 'memory stores', and specifies the output format (summaries with id, name, description, metadata). It distinguishes from sibling 'memory_store_get' (single store retrieval) and other listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: identifies memory stores as agent's persistent memory, explains how to attach the correct store via session_start, warns about consequences of using wrong store, and hints at pagination via next_page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It clearly indicates a read operation ('Get') and describes the output content, but does not explicitly state it is non-destructive or mention any auth requirements or rate limits. However, the nature of 'get' implies safety, and the description is thorough enough.
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?
Two sentences: first states purpose, second provides crucial usage instructions. No wasted words, front-loaded with purpose, and every sentence adds value.
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?
Given the simplicity of the tool (one parameter, output schema exists), the description is complete. It explains the purpose, the output content, and how to use the output in context (preparing a session), referencing sibling list tools for matching.
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?
Only one parameter 'agent_id' with 0% schema description coverage. The description adds context by specifying the ID pattern 'agent_*', which helps the agent understand the expected format beyond the schema.
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 clearly states it retrieves a single agent's full configuration by ID, using the specific verb 'Get' and resource 'agent configuration'. It distinguishes from sibling tools like agent_list (which lists all) and other get tools for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: read this before starting a session, use the retrieved configuration to determine required environment, vaults, and memory stores, then match against list tools. This tells when to use the tool and what to do with the output, implying when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses read-only behavior, polling semantics, pagination mechanics, truncation of large payloads, and common event types. This gives a comprehensive understanding of the tool's behavior.
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?
The description is front-loaded with the purpose and well-structured with clear sections. It is relatively concise but includes necessary detail. Slight room for tightening, but overall effective.
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?
Given the tool's complexity (polling, filtering, pagination) and the presence of an output schema, the description is complete. It covers all key usage aspects and common event types, allowing the agent to use it without ambiguity.
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?
Schema description coverage is 0%, so the description must compensate. It explains `since` (polling token), `types` (filters with examples), and `page` (pagination token). However, `limit` is not explicitly described, though pagination and truncation are covered. Overall, it adds significant meaning beyond the schema.
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 clearly states 'Read a session's events — the agent's output and activity.' The verb 'Read' and resource 'session's events' are specific, and the tool is distinct from sibling tools like session_get or session_interrupt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit polling guidance: 'POLL this to observe.' It explains how to use `since` for consecutive polls, `types` for filtering (with examples like agent.message), and `page` for pagination with the `has_more` flag. This tells the agent exactly when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavior: attaches vaults/memory stores, sends message, pins version, returns session_id. Warns about consequences of wrong resources.
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?
Well-structured with steps and bullet lists, front-loaded purpose. Slightly verbose but every sentence adds value; minor redundancy in resource assembly instructions.
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?
Thoroughly covers prerequisites, parameter meaning, invocation steps, and post-call observation. Completes the picture for a complex tool with dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates by explaining each parameter: vault_ids (vlt_*), memory_store_ids (memstore_*), message (first instruction), agent_version (pin version). Required params implied.
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?
Description starts with a clear verb+resource: 'Start a managed-agent session.' It distinguishes from sibling tools like session_get, session_list by focusing on session creation with resource attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step prerequisites (assemble resources using agent_get, list tools) and warns against bare or mismatched resources. Includes post-invocation polling instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![managed-agent-control-mcp MCP server](https://glama.ai/mcp/servers/modus-agendi/managed-agent-control-mcp/badges/card.svg)](https://glama.ai/mcp/servers/modus-agendi/managed-agent-control-mcp)

Score Badge

Copy to your README.md:

[![managed-agent-control-mcp MCP server](https://glama.ai/mcp/servers/modus-agendi/managed-agent-control-mcp/badges/score.svg)](https://glama.ai/mcp/servers/modus-agendi/managed-agent-control-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/modus-agendi/managed-agent-control-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server