Skip to main content
Glama

Update monitored company

update_monitored_company

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": {
      "agent_id": "<agent_id>",
      "identifier": "<identifier>"
    },
    "name": "update_monitored_company"
  }
}

Input Schema

NameRequiredDescriptionDefault
stageNo'active' or 'removed' (optional)
agent_idYesID of the agent
identifierYesThe company's display name or domain.
data_updatesNoDict to merge into existing data (optional)
on_behalf_ofNoA teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / on_behalf_of / description
      Previous value: -"An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."New value: +"A teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
  2. Changed2 schema fields changed
    • addedInput schema / properties / on_behalf_of
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
      +}
    • changedInput schema / properties / stage / anyOf
      Previous value: -[
      -  {
      -    "enum": [
      -      "active",
      -      "removed"
      -    ],
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "active",
      +      "removed"
      +    ],
      +    "title": "Stage",
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  3. Changed3 schema fields changed
    • addedInput schema / properties / agent_id
      Added value: +{
      +  "description": "ID of the agent",
      +  "type": "integer"
      +}
    • removedInput schema / properties / task_id
      Removed value: -{
      -  "description": "ID of the task",
      -  "type": "integer"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "task_id",
      -  "identifier"
      -]New value: +[
      +  "agent_id",
      +  "identifier"
      +]
  4. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation profile is known. The description usefully adds the operational consequence of stage='removed' (unwatched by the nightly sweep), but says nothing about permissions, what happens if the identifier does not match, or how partial data_updates merge conflicts are resolved.

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 summary is front-loaded with the action and the stage semantics, and the returns block is a single line. The XML-style tags add slight noise but each sentence carries 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?

For a 5-parameter mutation with no output schema, it covers the action, the key state change, and the return shape ('dict with the updated company details'). Remaining gaps are error/not-found behavior and ambiguity when only data_updates is supplied.

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 100%, so baseline is 3, but the description earns credit above that by explaining the runtime effect of the stage values rather than just restating the enum. The on_behalf_of and agent_id parameters get no elaboration beyond the schema, which is acceptable given the schema already documents them.

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 opens with a specific verb and resource ('Update a single monitored company') and names exactly which fields are mutable (stage and/or data), which separates it from query_monitored_companies and track_monitored_companies. It does not explicitly name those siblings, so an agent must infer the boundary.

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 clear conditional guidance for the main branch point: stage='removed' stops the nightly sweep, 'active' resumes it. It does not say when to prefer this over track_monitored_companies or edit_monitor_members, so routing to the correct sibling is left to inference.

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.

Resources