Skip to main content
Glama
morluto

jacobian

by morluto
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Discover mathematical capabilities

capability.describe
Read-onlyIdempotent

Discover installed mathematical outcomes by query or inspect a capability contract for its input schema, runtime identity, and verified examples before invoking.

Instructions

Discover installed mathematical outcomes or inspect one exact capability contract.

Use this first when a task may benefit from exact computation, structural analysis, transformation, bounded search, counterexample generation, formal-environment inspection, or independent checking. You do not need to know a capability ID.

Discovery:

  • Pass query to rank compact installed outcomes by mathematical intent.

  • Optionally filter with domain and mode; limit is between 1 and 20 and defaults to 5.

  • Omit all arguments to browse a compact installed catalog.

  • When next_cursor is present, pass it back with the same filters and limit to continue without loading the complete catalog.

  • Ranking is deterministic retrieval over published IDs, titles, descriptions, and tags. Match fields and terms are returned; results are candidates, not recommendations.

  • Once a domain-owned match fits the required outcome, inspect only the strongest one or two candidates. Search again when none fits. Invoke a producer before looking for its checker, then follow the checker, certificate, and verification fields in the producer result instead of guessing a generic verifier.

  • Compose capabilities as the investigation requires; Jacobian does not prescribe a mathematical workflow.

Exact inspection:

  • Pass capability_id for the small default SUMMARY projection when judging fit.

  • Request view="CONTRACT" once a capability fits and before invoking it. CONTRACT adds the validation-equivalent input schema, runtime identity, related operations, and validated invocation examples.

  • Add view="FULL" only when complete output schema, provider configuration, licensing, or audit metadata is needed.

  • Every exact response states the scope rule: repeated bounded invocations remain finite evidence and do not establish an all-orders or all-parameters conclusion.

Examples:

  • {"query":"find a counterexample to associativity","domain":"universal_algebra","mode":"EXPLORE","limit":5}

  • {"query":"verify a polynomial identity","mode":"VERIFY","limit":5}

  • {"capability_id":"polynomial.compute.gcd"}

  • {"capability_id":"polynomial.compute.gcd","view":"CONTRACT"}

  • {"capability_id":"polynomial.compute.gcd","view":"FULL"}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoOptional EXPLORE or VERIFY capability filter.
viewNoExact-lookup projection. SUMMARY is the small agent-facing default for judging fit. CONTRACT adds the validation-equivalent input schema, runtime identity, related operations, and validated invocation examples; request it before invoking. FULL returns the complete installed descriptor for audit or client generation. Omit for discovery.SUMMARY
limitNoMaximum compact discovery matches; defaults to 5. Start with 5 and inspect only the strongest one or two candidates.
queryNoMathematical outcome to find; no capability ID is required.
cursorNoOpaque continuation ID from next_cursor. Reuse the same query, domain, mode, input kind, artifact type, and limit.
domainNoOptional domain tag filter, such as universal_algebra, graph, polynomial, or lean.
input_kindNoInput boundary used to reject incompatible routes.
artifact_typeNoExact schema_uri from the stored artifact manifest; requires TYPED_ARTIFACT.
capability_idNoExact installed ID; cannot be combined with discovery filters.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Tool Definition Quality

A5/5.0
Behavior5/5

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

Annotations already declare the read-only, idempotent, non-destructive profile; the description adds significant behavioral context: deterministic ranking, results as candidates not recommendations, the scope rule for repeated bounded invocations, and the cursor continuation requirements. This goes well beyond the annotation hints and no contradiction exists.

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 long but exceptionally well-structured: an intro sentence, when-to-use paragraph, bulleted discovery and exact-inspection sections, and examples. Every sentence adds value, and the format makes scanning easy. It is sized appropriately for a tool with two operational modes and nine parameters.

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?

Given the tool's complexity (two modes, three views, cursor pagination, multiple optional filters), the description fully covers discovery workflow, exact inspection workflow, and the epistemic scope rule. It does not need to explain return values because an output schema exists, and it provides sufficient guidance for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the input schema documents all 9 parameters (100% coverage), the description adds crucial usage semantics: query ranks by mathematical intent, limit defaults to 5 and must be 1-20, cursor requires reusing the same filters, capability_id cannot be combined with discovery filters, and view levels SUMMARY/CONTRACT/FULL have specific purposes. It also provides concrete examples that map to the schema.

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 statement ('Discover installed mathematical outcomes or inspect one exact capability contract'), distinguishing two operational modes. It clearly differentiates from siblings by stating 'Use this first...' and noting no capability ID is needed for discovery.

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?

Explicitly states when to use this tool: 'Use this first when a task may benefit from exact computation, structural analysis...' and provides guidance on when to use discovery vs exact inspection, view selection, and how to handle cursor pagination. It also instructs to compose capabilities and follow producer results rather than guessing a generic verifier.

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/morluto/jacobian'

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