get_more_toolsCheck for additional specialised capabilities whenever your task might benefit from them. Also the right tool for a bare greeting or a liveness test — pass it as context and this returns the menu instead of a dead end.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | What you are trying to do. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by stating that passing a greeting or liveness test as context 'returns the menu instead of a dead end'. This discloses the tool's response behavior. Annotations already cover read-only, idempotent, non-destructive traits, so the description's additional context is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the primary purpose, then adds the secondary use case and outcome in a compact, scannable way. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with strong annotations and no output schema, the description is complete: it explains what the tool does, when to use it, what to pass, and what to expect in return. No obvious missing information would prevent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes context as 'What you are trying to do.' The description adds value by explicitly naming the parameter in usage ('pass it as `context`') and giving concrete examples like greetings and liveness tests, which enrich the schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a specific verb and resource: 'Check for additional specialised capabilities' and 'returns the menu'. It also positions the tool against the sibling tools by indicating it is the meta/capability-discovery entry point rather than a domain-specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use guidance: whenever a task might benefit from additional capabilities, and specifically for bare greetings or liveness tests. It does not explicitly name alternatives or list exclusions, but 'check here first' implies priority over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most domain tools are cleanly separated: launch readiness, speaker readiness, topic evaluation, leadership benchmarking, partnership business case, and reach purchasing each map to a distinct workflow. The only real ambiguity is between get_started and get_more_tools, which both claim greeting/liveness/menu duties, so an agent might call the wrong one for those entry-point cases.
Tool names are consistently imperative snake_case with clear verbs and objects (assess_*, benchmark_*, build_*, buy_*, evaluate_*). get_more_tools and get_started are slightly less resource-specific, and get_started is a phrasal verb rather than a strict verb_noun action, but the overall style is uniform.
Eight tools is a well-scoped size for a community/partnership decision-support server. It is within the ideal range and each core workflow has its own tool without the set feeling bloated.
The set covers the main workflows: readiness checks, topic/speaker evaluation, leadership benchmarking, partnership business cases, and reach purchasing. It lacks operational follow-through like membership signup, event scheduling, or post-assessment action plans, but those are adjacent rather than core to the apparent purpose.