Skip to main content
Glama

ISMS Copilot

by io.github.tristanroth1
OverviewDiscussionsAdmin

send_message

Continue a conversation with the ISMS Copilot GRC specialist on the same deliverable: refine the same policy, extend the same gap analysis, or ask the next question. Use it with the conversation_id that create_conversation returned. Do not use it to start a new deliverable (create_conversation), or while the previous turn is still generating: wait for get_reply, since a send then is rejected. assistant (optional): switches the assistant from this turn on; omit to keep it, 'general' for the general specialist. Rule: a task to do takes the job id even when it names a framework; a question about one framework takes that framework's id; else omit assistant.

  • questionnaire-responder: use when answering or assessing a security questionnaire

  • audit-prep: use when preparing an internal or external audit

  • implementation-lead: use when asked for a plan or roadmap to implement or certify a framework

  • incident-lead: use when an incident or breach is under way or just happened (what now, notification duties)

  • iso27701: use when about ISO 27701 privacy management

  • iso42001: use when about ISO 42001 AI management

  • nis2: use when about NIS 2

  • dora: use when about DORA

  • eu-ai-act: use when about the EU AI Act

  • cra: use when about the Cyber Resilience Act Options: mode and answer_format as on create_conversation. Returns conversation_id, message_id and status: 'complete' with response, or 'generating': then poll get_reply. Limit errors include reset_at and what to do; when one carries fallback_available: true, resend the same message with overflow_consent: true only on the user's explicit go-ahead (no duplicate message is saved). Relay docgen_notice to the user when present. Do not include passwords, API keys, payment card numbers, health records or government ID numbers. Answers are informational, not legal advice.

Input Schema

NameRequiredDescriptionDefault
modeNoReasoning depth: 'fast' (default), 'think' (paid plans), or 'beyond' (paid plans; agentic multi-step run, minutes-scale, poll get_reply).
messageYesThe follow-up question or request, in the user's words.
assistantNoOptional: switch this conversation's assistant from this turn on: 'general' or an id from list_assistants. Omit to keep the current one.
answer_formatNoOptional reply format for an agent caller: 'brief' (shortest correct answer, about 150 words), 'decision' (recommendation first, then why, risks and next steps as bullets, about 300 words), or 'full' (the default chat style). Omit for the default. An explicitly requested full document is never cut short.
conversation_idYesConversation id (a UUID returned by create_conversation).
overflow_consentNoSet true ONLY when the user explicitly asks to continue past their usage limit. On eligible paid accounts (ADP off, non-Essential) over the 4h cap, the turn then runs on the disclosed fallback models up to an additional 2x the plan's token limit. Resending the SAME message text resumes the capped turn without duplicating it. Ignored on free, Essential, ADP, or team-pool accounts and when the overflow bucket is exhausted (fallback_exhausted: true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / conversation_id / description
      Added value: +"Conversation id (a UUID returned by create_conversation)."
    • addedInput schema / properties / message / description
      Added value: +"The follow-up question or request, in the user's words."
  2. Changed1 schema field changed
    • addedInput schema / properties / assistant
      Added value: +{
+  "description": "Optional: switch this conversation's assistant from this turn on: 'general' or an id from list_assistants. Omit to keep the current one.",
+  "type": "string"
+}
  3. Changed2 schema fields changed
    • changedInput schema / properties / mode / description
      Previous value: -"Reasoning depth: 'fast' (default), 'think' for deeper reasoning, or 'beyond' for a longer multi-step run (minutes; poll get_reply). think and beyond are not available on every plan; the turn then answers in fast mode."New value: +"Reasoning depth: 'fast' (default), 'think' (paid plans), or 'beyond' (paid plans; agentic multi-step run, minutes-scale, poll get_reply)."
    • changedInput schema / properties / overflow_consent / description
      Previous value: -"Set true only when the user explicitly asks to continue past their usage limit. Where the account allows it, the turn then continues on a faster model; otherwise it is ignored."New value: +"Set true ONLY when the user explicitly asks to continue past their usage limit. On eligible paid accounts (ADP off, non-Essential) over the 4h cap, the turn then runs on the disclosed fallback models up to an additional 2x the plan's token limit. Resending the SAME message text resumes the capped turn without duplicating it. Ignored on free, Essential, ADP, or team-pool accounts and when the overflow bucket is exhausted (fallback_exhausted: true)."
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only mark it as non-read-only and open-world; the description adds far more: the return shape (conversation_id, message_id, status 'complete' vs 'generating' → poll get_reply), rate-limit errors carrying reset_at, the fallback_available/overflow_consent path with the explicit-user-consent precondition and the no-duplicate-save guarantee, docgen_notice relaying, and a data-sensitivity prohibition. That is substantive behavioral context beyond the annotation set.

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?

Front-loaded correctly: purpose and the two negative routing rules come first, then parameter nuance, then return/error behavior, then safety. Every block is functional, though the ten-bullet assistant catalogue is long and largely recoverable via list_assistants, which makes it slightly heavier than necessary.

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?

There is no output schema, so the description carries the burden of describing returns — it does, including the 'generating' state and the polling handoff. Combined with error-path guidance, the consent rule, and the privacy constraint, an agent has everything needed to call this correctly, including what to tell the user afterwards.

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 the baseline is 3, and the description earns above that by adding selection logic the schema lacks (the assistant routing rule and the note that mode/answer_format mirror create_conversation) plus the consent gate on overflow_consent. It stops short of 5 because much of the assistant detail restates ids the schema already points at via list_assistants.

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?

Opens with a specific verb and resource ('Continue a conversation with the ISMS Copilot GRC specialist on the same deliverable') and even enumerates the continuation shapes: refine a policy, extend a gap analysis, ask the next question. It explicitly contrasts itself with create_conversation (new deliverable) and get_reply (in-flight turn), so an agent can place it among siblings without reading schemas.

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?

Gives both positive triggers and explicit exclusions with the correct alternative named for each: don't start a new deliverable (use create_conversation), don't send while the previous turn is generating (wait for get_reply, 'a send then is rejected'). It also supplies a decision rule for the optional assistant parameter ('a task to do takes the job id... a question about one framework takes that framework's id; else omit'), which is exactly the guidance an agent needs.

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

All ISMS Copilot toolsInspect
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