registree

Overview Schema Source Related Servers Discussions Admin

get_signature

Verify a class before use: retrieve its constructor arguments, accepted keywords, and method list to ensure calls are valid and avoid hallucinated parameters.

Instructions

Constructor contract AND callable surface for a class — EVERY definition if the name is duplicated. Call this before writing an instantiation or a method call: it reports the required arguments, the accepted keywords, honest null when a constructor is open-ended or unknowable, and the class's methods (inherited included, each with its kind and defining class) so a method name can be verified rather than guessed. When methods_complete is false an ancestor was unresolvable, so a listed method exists but an unlisted one still might.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`class_name`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`note`	Yes
`found`	Yes
`ambiguous`	Yes
`class_name`	Yes
`definitions`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.3.0Aug 26, 2026

addedOutput schema / $defs / Definition / properties / methods

Added value: +{
+  "items": {
+    "$ref": "#/$defs/MethodSummary"
+  },
+  "title": "Methods",
+  "type": "array"
+}

addedOutput schema / $defs / Definition / properties / methods_complete

Added value: +{
+  "title": "Methods Complete",
+  "type": "boolean"
+}

changedOutput schema / $defs / Definition / required

Previous value: -[
-  "file_path",
-  "line_number",
-  "type",
-  "module",
-  "file_type",
-  "parent_classes",
-  "summary",
-  "init_signature",
-  "fields",
-  "required_arguments",
-  "accepted_keywords"
-]New value: +[
+  "file_path",
+  "line_number",
+  "type",
+  "module",
+  "file_type",
+  "parent_classes",
+  "summary",
+  "init_signature",
+  "fields",
+  "methods",
+  "methods_complete",
+  "required_arguments",
+  "accepted_keywords"
+]

addedOutput schema / $defs / MethodSummary

Added value: +{
+  "properties": {
+    "accepts_kwargs": {
+      "title": "Accepts Kwargs",
+      "type": "boolean"
+    },
+    "defined_in": {
+      "title": "Defined In",
+      "type": "string"
+    },
+    "is_async": {
+      "title": "Is Async",
+      "type": "boolean"
+    },
+    "kind": {
+      "title": "Kind",
+      "type": "string"
+    },
+    "name": {
+      "title": "Name",
+      "type": "string"
+    },
+    "returns": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "title": "Returns"
+    },
+    "signature": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "title": "Signature"
+    }
+  },
+  "required": [
+    "name",
+    "signature",
+    "kind",
+    "is_async",
+    "accepts_kwargs",
+    "returns",
+    "defined_in"
+  ],
+  "title": "MethodSummary",
+  "type": "object"
+}

First observedv0.1.0Aug 22, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden, and it does so thoroughly. It discloses important behavioral details: duplicate definitions are all returned, null is returned only in specific constructor cases, inherited methods are included with kind and defining class, and the methods_complete=false caveat about unresolvable ancestors is explicitly explained.

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 dense but information-rich, front-loading the core purpose and then detailing edge cases and caveats. It is slightly verbose and uses informal phrasing like 'honest null' and 'EVERY definition,' but every sentence adds meaningful behavioral 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?

The description covers the tool's output surface, when to use it, duplicate-name behavior, and the methods_complete caveat, and an output schema is present. It does not address error cases or class_name resolution format, but for a single-parameter introspective tool it is largely sufficient.

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 has only one parameter, class_name, with no parameter description, and the description does not explicitly document the expected format (e.g., fully qualified vs. simple name, case sensitivity). It does add some meaning by noting that duplicate names return every definition, but it leaves format and resolution details implicit.

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 names a specific resource ('a class') and a precise result: the constructor contract and callable surface, including required arguments, accepted keywords, methods, and inherited methods. It clearly distinguishes get_signature from siblings like search_classes, list_duplicates, verify_snippet, and get_usages by what it returns and when it is meant to be called.

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 guidance: 'Call this before writing an instantiation or a method call.' It conveys the intended use context clearly but does not explicitly name alternative tools or state when not to use this tool, so it stops short of a 5.

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

Deploy Server