Skip to main content
Glama

contact_depscope

Submit tickets for bugs, new package/ecosystem listings, security disclosures, output anomalies with evidence, or partnership requests. Returns ticket or anomaly ID for tracking.

Instructions

Inbound ticket: bug/listing/security/anomaly/partnership. USE WHEN: reporting wrong data (bug), requesting a new pkg/ecosystem index (listing), disclosing a DepScope security issue (security), flagging a concrete mismatch in another tool's output vs. authoritative source (anomaly — provide tool_called+observed+expected), or partnership/press (partnership). RETURNS: {ticket_id} or {anomaly_id}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoTicket category. `anomaly` routes to structured anomaly triage (requires tool_called/observed/expected).
emailNoReply-to email of the requester (required for bug/listing/security/partnership).
subjectNoShort subject line (3-200 chars).
bodyNoMessage body (10-8000 chars). Be specific: include package name, ecosystem, error trace, repro steps when applicable.
nameNoSender display name (optional).
companyNoCompany / organization (optional).
tool_calledNoFor kind=anomaly: DepScope tool that produced the anomaly (e.g. check_package, get_migration_path).
ecosystemNoFor kind=anomaly: ecosystem of the involved package, if any.
packageNoFor kind=anomaly: package name involved, if any.
versionNoFor kind=anomaly: package version involved, if any.
observedNoFor kind=anomaly: what DepScope returned (1-1500 chars).
expectedNoFor kind=anomaly: what you expected to see (1-1500 chars). Be concrete.
evidence_urlNoFor kind=anomaly: URL to authoritative source (registry page, GHSA, CVE, repo, ...) supporting your expectation.

Implementation Reference

  • Handler for the contact_depscope tool in the handleToolCall dispatcher. Routes to /api/anomaly for 'anomaly' kind, or /api/contact otherwise. Also handles the back-compat alias report_anomaly.
    case "contact_depscope": {
      if (args.kind === "anomaly") {
        const body = JSON.stringify({
          tool_called: args.tool_called,
          ecosystem: args.ecosystem || "",
          package: args.package || "",
          version: args.version || "",
          observed: args.observed,
          expected: args.expected,
          evidence_url: args.evidence_url || "",
          source: "mcp",
        });
        const res = await fetch(`${API_BASE}/api/anomaly`, {
          method: "POST",
          headers: { "Content-Type": "application/json", "X-Depscope-Source": "mcp", "X-MCP-Tool": name },
          body,
        });
        if (!res.ok) return fail(`contact_depscope(anomaly) failed: ${res.status} ${await res.text().catch(()=>"")}`);
        return ok(await res.json());
      }
      const body = JSON.stringify({
        email: args.email,
        subject: args.subject,
        body: args.body,
        type: args.kind || args.type || "other",
        name: args.name || "",
        company: args.company || "",
        source: "mcp",
        consent: true,
      });
      const res = await fetch(`${API_BASE}/api/contact`, {
        method: "POST",
        headers: { "Content-Type": "application/json", "X-Depscope-Source": "mcp", "X-MCP-Tool": name },
        body,
      });
      if (!res.ok) return fail(`contact_depscope failed: ${res.status} ${await res.text().catch(()=>"")}`);
      return ok(await res.json());
    }
  • Tool definition/schema for contact_depscope in the TOOLS array. Defines name, description, annotations (non-idempotent), and inputSchema with properties: kind, email, subject, body, name, company, tool_called, ecosystem, package, version, observed, expected, evidence_url.
    // ── 8. Feedback channel (NOT idempotent — creates a ticket) ─────────
    {
      name: "contact_depscope",
      description:
        "Inbound ticket: bug/listing/security/anomaly/partnership. USE WHEN: reporting wrong data (`bug`), requesting a new pkg/ecosystem index (`listing`), disclosing a DepScope security issue (`security`), flagging a concrete mismatch in another tool's output vs. authoritative source (`anomaly` — provide tool_called+observed+expected), or partnership/press (`partnership`). RETURNS: {ticket_id} or {anomaly_id}.",
      annotations: {
        title: "contact_depscope",
        readOnlyHint: false,
        destructiveHint: false,
        idempotentHint: false,
        openWorldHint: true,
      },
      inputSchema: {
        type: "object",
        properties: {
          kind: { type: "string", enum: ["bug","listing","security","anomaly","partnership"], description: "Ticket category. `anomaly` routes to structured anomaly triage (requires tool_called/observed/expected)." },
          email: { type: "string", description: "Reply-to email of the requester (required for bug/listing/security/partnership)." },
          subject: { type: "string", description: "Short subject line (3-200 chars)." },
          body: { type: "string", description: "Message body (10-8000 chars). Be specific: include package name, ecosystem, error trace, repro steps when applicable." },
          name: { type: "string", description: "Sender display name (optional)." },
          company: { type: "string", description: "Company / organization (optional)." },
          tool_called: { type: "string", description: "For kind=anomaly: DepScope tool that produced the anomaly (e.g. check_package, get_migration_path)." },
          ecosystem: { type: "string", description: "For kind=anomaly: ecosystem of the involved package, if any." },
          package: { type: "string", description: "For kind=anomaly: package name involved, if any." },
          version: { type: "string", description: "For kind=anomaly: package version involved, if any." },
          observed: { type: "string", description: "For kind=anomaly: what DepScope returned (1-1500 chars)." },
          expected: { type: "string", description: "For kind=anomaly: what you expected to see (1-1500 chars). Be concrete." },
          evidence_url: { type: "string", description: "For kind=anomaly: URL to authoritative source (registry page, GHSA, CVE, repo, ...) supporting your expectation." },
        },
      },
    },
  • Registration via ListToolsRequestSchema (returns TOOLS array) and CallToolRequestSchema (calls handleToolCall) in stdio entry point.
    server.setRequestHandler(ListToolsRequestSchema, async () => ({ tools: TOOLS }));
    server.setRequestHandler(CallToolRequestSchema, async (req) =>
      handleToolCall(req.params.name, req.params.arguments || {})
    );
  • Registration via ListToolsRequestSchema (returns TOOLS array) and CallToolRequestSchema (calls handleToolCall) in Streamable HTTP entry point.
    s.setRequestHandler(ListToolsRequestSchema, async () => ({ tools: TOOLS }));
    s.setRequestHandler(CallToolRequestSchema, async (req) =>
      handleToolCall(req.params.name, req.params.arguments || {})
    );
  • Helper functions ok() and fail() used by the handler to format success/error responses.
    function ok(data) {
      const text = typeof data === "string" ? data : JSON.stringify(data, null, 2);
      return { content: [{ type: "text", text }] };
    }
    function fail(message) {
      return { content: [{ type: "text", text: `Error: ${message}` }], isError: true };
    }
Behavior3/5

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

Annotations provide readOnlyHint=false, destructiveHint=false, and the description adds return value details (ticket_id or anomaly_id). The description is consistent with annotations but does not add significant behavioral context beyond what is implied.

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 (two sentences with clear enumeration) and front-loaded with purpose. Every part earns its place with no waste.

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 complex parameter set and no output schema, the description adequately explains what the tool returns and the purpose of each kind. It lacks details on prerequisites or rate limits but is sufficient for an agent.

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?

Input schema has 100% coverage with parameter descriptions. The description groups parameters by kind but does not add new meaning beyond what's in the schema. Baseline 3 is appropriate.

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 creates inbound tickets for specific categories (bug, listing, security, anomaly, partnership). It distinguishes from sibling tools by focusing on ticket submission rather than package checking.

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 lists 'USE WHEN' conditions for each kind and provides specific context for anomaly. It does not explicitly state when not to use or mention alternatives, but 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.

Install Server

Other Tools

Latest Blog Posts

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/cuttalo/depscope'

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