Skip to main content
Glama
DanCommitsGit

openai-mcp

by DanCommitsGit
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Count tokens

count_tokens
Read-only

Counts the input tokens a generate_text request would use for a prompt, model, optional images, instructions, and web search, without running the model.

Instructions

Count the input tokens a generate_text request would use, without running the model

Input Schema

NameRequiredDescriptionDefault
modelYesOpenAI model whose tokenizer to use. Must support image input if images are provided
imagesNoImages to include in the count, each as an http(s) URL or a file path on this server's filesystem (PNG, JPEG, WEBP, or GIF)
promptYesThe input text to count
webSearchNoCount the request as one that has web search enabled
instructionsNoOptional instructions to include in the count

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • addedInput schema / properties / webSearch
      Added value: +{
+  "description": "Count the request as one that has web search enabled",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description reinforces the key trait: no model invocation, so no cost or side effects from the call itself. It does not mention how faithful the estimate is versus the real generate_text count, but with annotations carrying the safety profile this is a solid addition rather than a gap.

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?

A single front-loaded sentence with the core verb first and the crucial non-execution caveat attached. Nothing extraneous, nothing buried.

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?

For a simple read-only utility with a fully described schema and no output schema, the description covers purpose and behavior adequately. The one missing piece is what the response looks like (a token count integer, or a breakdown per input channel), which would matter when images and instructions are supplied.

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?

Schema coverage is 100%, so all five parameters (model, prompt, images, webSearch, instructions) are already documented in the schema. The description adds only the framing that the count mirrors a generate_text request, which is marginal but useful for interpreting webSearch and instructions. Baseline 3 applies.

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?

Specific verb (count) plus resource (input tokens) plus the exact consumer it is modeling (a generate_text request), and the qualifier 'without running the model' separates it cleanly from the sibling generate_text. An agent can tell immediately what this does and what it does not do.

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?

'without running the model' implicitly frames the use case: estimating token/cost load before invoking generate_text. That is clear context, but there is no explicit when-not guidance or pointer to a sibling alternative for other counting needs (e.g. embeddings or moderation inputs).

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