Skip to main content
Glama
Ikalus1988

MisakaNet

by Ikalus1988
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

misakanet_me_events

Return evidence that a debugging lesson was actually reused by real clients. Requires a lesson ID or path; otherwise returns an error.

Instructions

[READ-ONLY EVIDENCE] Return evidence of a lesson being reused. E4 is observed reuse: search_signals shows two or more distinct clients actually retrieved the lesson — a count of requests, never of prose. Regression-benchmark citations, helpful votes and a lesson's own verified by: line are E3 hints: a citation is sandbox-level evidence, a vote is one person's opinion, and a provenance line is the lesson talking about itself, so none of them can confer E4. Use to check whether a lesson is proven by real usage, not just self-reported. Provide lesson_id or lesson_path — if neither is supplied the tool returns {error}. Semantically 'misakanet_get_my_events' (evidence for the lessons your node submitted/used); kept as me_events for backward compatibility. No auth required (read-only, rate-limited). Returns: object {lesson_id, events: [{type, count|queries|sources, evidence_level}], evidence: 'E0'|'E3'|'E4', note}. Example: misakanet_me_events(lesson_id='dco-auto-fix-workflow') Input semantics: lesson_id (filename stem, e.g. dco-auto-fix-workflow) or lesson_path (e.g. lessons/core/dco-auto-fix-workflow.md) — the endpoint derives the id from the path the same way. Passing neither is refused before any network call. Output schema: proxied unchanged from the hosted tool (lesson_id, events[], evidence, note). Error cases: missing_lesson_reference when both arguments are absent; hosted_endpoint_unavailable when the hosted service cannot be reached or refuses the call — this is a proxy, so there is no local fallback, and an empty events list would be a different, wrong answer. Side effects: none (read-only, no local writes). Auth: none. Rate limits: the hosted endpoint's anonymous read burst window applies; the proxy adds no local limit.

Input Schema

NameRequiredDescriptionDefault
lesson_idNoLesson ID (filename stem), e.g. dco-auto-fix-workflow. Either lesson_id or lesson_path is required.
lesson_pathNoOptional full path, e.g. lessons/core/dco-auto-fix-workflow.md. Either lesson_id or lesson_path is required.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.43.0
    • removedInput schema / minProperties
      Removed value: -1
    • addedInput schema / oneOf
      Added value: +[
+  {
+    "required": [
+      "lesson_id"
+    ]
+  },
+  {
+    "required": [
+      "lesson_path"
+    ]
+  },
+  {
+    "required": [
+      "lesson_id",
+      "lesson_path"
+    ]
+  }
+]
  2. Addedv2.40.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: read-only with no side effects or local writes, no auth, the hosted endpoint's anonymous read burst rate window, no local fallback as a proxy, and named error cases (missing_lesson_reference, hosted_endpoint_unavailable) plus the warning that an empty events list would be a different, wrong answer. It also discloses the key semantic caveat that only real client retrievals confer E4, which no structured field conveys.

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 with a [READ-ONLY EVIDENCE] tag and the core distinction, then organized into Returns/Input/Errors/Side effects/Auth/Rate limits. The E3-vs-E4 exposition is long but earns its place for correct interpretation; there is minor redundancy across the two auth/read-only statements.

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?

No output schema exists, so the description supplies the return shape (lesson_id, events[{type, count|queries|sources, evidence_level}], evidence, note). Combined with explicit side effects, auth, rate limits, and error taxonomy, nothing an agent needs to call or interpret this tool correctly is missing.

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 would be 3, but the description adds meaning beyond the schema: lesson_id is a filename stem while lesson_path has its id derived from the path 'the same way', and passing neither is refused before any network call — clarifying the oneOf semantics operationally.

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 opens with a specific verb+resource: 'Return evidence of a lesson being reused', and immediately scopes it to E4 observed reuse (client retrieval counts) versus E3 hints like citations and votes. It also names its semantic alias (misakanet_get_my_events) and distinguishes scope ('evidence for the lessons your node submitted/used'), so an agent can separate it from get_lesson or search.

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?

Explicit when-to-use is given: 'Use to check whether a lesson is proven by real usage, not just self-reported', plus the hard precondition that one of lesson_id/lesson_path must be supplied or the call is refused. It never names a sibling tool as the alternative for the adjacent task (e.g., fetching lesson prose), so it is clear context but not full when/when-not routing.

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

Deploy Server

Other Tools