Skip to main content
Glama
Sign In
Devtrack MCP Server

Devtrack MCP Server

by sraj0501
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get voice profile

get_voice_profile
Read-onlyIdempotent

Retrieve the developer's writing style profile for a specified context to tailor your output accordingly.

Instructions

Returns the developer's inferred writing style profile for a given context type. Use this to understand how the developer prefers to communicate before generating text on their behalf.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_voice_profile"
  }
}

Input Schema

NameRequiredDescriptionDefault
context_typeNoThe writing context to retrieve style inferences for.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.1.1

TDQS

A4.1/5.0
Behavior3/5

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

The annotations already indicate read-only, idempotent, and non-destructive behavior. The description does not add any additional behavioral traits such as caching, error conditions, or side effects. It simply says 'returns', which is consistent with the annotations but does not go beyond them, so it meets the baseline but not higher.

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 two sentences long, free of jargon or redundant phrases, and gets straight to the point. It clearly states what the tool does and when to use it without any unnecessary details.

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?

For a simple getter with a single parameter and no output schema, the description is complete. It tells the agent what the tool returns, the purpose of the parameter, and the use case, so nothing essential is missing.

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 description for context_type already explains it as 'The writing context to retrieve style inferences for' with an enumerated list of values. The tool description only repeats this in different words ('given context type') without adding any new meaning or nuance, so the description adds no value beyond 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 clearly states it returns a writing style profile for a given context type, which is distinct from the sibling tools that deal with other types of information. The verb 'returns' is specific and the resource 'developer's inferred writing style profile' is well-defined.

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?

It explicitly says to use this tool to understand the developer's communication preferences before generating text, which is a clear when-to-use. However, it does not mention when not to use it or compare it to alternative tools, such as get_active_context or get_today_commits, so it lacks the explicit alternatives that would earn 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

Other Tools